Can I add another raise-argument-error function that takes an extra bad-arg-name argument so the programmer can specify which argument is being referred to when an argument error exception is raised? I’d like to be able to clearly refer to the name of an argument in a uniform format consistent with the format of the error messages raised by the other two raise-argument-error functions.

raise-arguments-error offers something similar in that you can specify which argument fields are involved but the error message format is not the same as raise-argument-error which is undesirable from my point of view.

@mflatt Why is the backing type of _enum _ufixint? When the c spec states that it’s _int?

(Section 6.4.4.3: “An identifier declared as an enumeration constant has type int”)

this is perhaps a super naive question, but if i want to build a parallel app, what’s the state of this in racket? I believe the GC is not thread friendly, and I don’t think the move to chez will make that any easier

@krismicinski if what you want is to execute two separate computations that don’t share much, then places work pretty well

this is how parallel builds and background expansion work

cool, thanks

if what you want is shared memory parallelism then the support is not very good

Yeah, I’m thinking of moving one of our symbolic executors to racket. Threads don’t really need to communicate much at all, since they are forking off and doing various amounts of work in a pool, but coordinating them will require some thought no matter what

that sounds like something that would work fine

places is, I assume, a library

yup, ok, great, will look into this

yes, this looks exactly like what I wanted. Basically a scheduler needs to be able to talk to some number of worker threads.

@krismicinski but if you want heave parallelism, you might want to look elsewhere. places break when you issue over 16 or so in the same machine. By break here I mean that they start spending too much time dealing with memory locking in the kernel.

I am just working on a library to solve this…

sorry, my apologies, but what is heave parallelism?

and yes, I can imagine that things scale sub-linearly because of these coordination vagaries..

really for what we’re doing, even something like 5–10 tasks would be fine

but we’d like something robust for the future. My guess is that the right architecture would be agnostic to the particulars of implementation.

Background is here: https://groups.google.com/d/msg/racket-users/oE72JfIKDO4/zbFI6knhAQAJ

the intent of places is that you only create at most one per core and schedule tasks over the pool, not that you spawn one per task

@lexi.lambda that’s even better!

@lexi.lambda true, but if your machine has 96 cores, places are not so good.

places scale ok for a big-desktop size machine, but poorly for really big machines

assuming you’re trying to use them all.

yes, I would believe that

@samth +1

right, we just have a 20-core machine and want our symbolic executor to be not-so-obviously-naive

it’s a super parallelizable problem: fork at various points, explore source, listen to a scheduler to decide what to explore next.

@krismicinski right, a lot like a build system, which works decently well

I think there’s a job queue pkg already somewhere

@krismicinski I would start architecting it with places and see how far you can go.

yeah, I think you are both right

okay, basically I was trying to figure out: if I rewrite this in racket, is it going to be basically impossible to scale at all. The state of our ocaml implementation is also not so promising, since ocaml does not have a good concurrency story (not terrible either, but not super friendly)

Didn’t know about the pkg @samth mentioned. Take a look at it first then. :slightly_smiling_face:

@krismicinski it will scale… I wouldn’t worry so much about that.

I was thinking of job-queue, but that’s just plain threads

might make the job a bit easier, though

@krismicinski just running a racket application on a 96 core, 386gb ram machine. Works great!

My guess is that the main issue will just be figuring out the right job queue abstraction at a high level, and after that using places should not be so bad

that’s awesome!!!

you might be interested in the code here: https://github.com/racket/typed-racket/blob/master/typed-racket-test/main.rkt

which has a job queue that uses places

@pocmatos how does your new library compare to using distributed places?

@samth by distributed you mean over several machines?

that’s not implemented yet but it’s doable and I will surely want to do it.

i mean using the distributed-places library (perhaps connecting to the local machine)

ah, you mean using distributed places but on the localhost?

yeah

yeah, this looks helpful, sam

Haven’t compared yet, but it’s definitely more straightforward to use since you don’t need to worry about nodes. It’s mostly the places API but using processes underneath.

https://github.com/racket/typed-racket/blob/master/typed-racket-test/places.rkt

This looks highly relevant

I’m not sure what it would mean to specify the “name” of an argument, since arguments don’t really have names at run time. But it would certainly make sense to have some descriptive text about the argument’s role.

@samth interestingly I found @mflatt tried something along these lines before in https://github.com/racket/racket/blob/master/pkgs/racket-benchmarks/tests/racket/benchmarks/places/place-processes.rkt

also I think there’s now a build system option for process-based places

I have taken that and structured it into a package but I had about half a day to work on it, so not really stable or anything but it’s here:

https://github.com/LinkiTools/racket-loci

see also http://docs.racket-lang.org/pmap/index.html

https://pkgs.racket-lang.org/package/loci-dev

yeah i saw that when i searched for the pkg that didn’t exist that I thought I remembered :slightly_smiling_face:

this distributed places stuff looks really nice

seems not so dissimilar to a better MPI

I don’t know why Eli originally make it _ufixint. Probably he wqas mostly looking at uses that count from 0.

What I mean by name of an argument; suppose we have (define (foo argA argB argC) ...) that does checking on argA argB and argC and uses raise-argument-error to inform users of any bad arguments. If argA is bad, I want to be able to have the name argA be mentioned in the error message. Right now the only options is to either mention the expected contract and the given value, or also specify which argument by position numbering.

Often in function’s documentation, names are given to arguments so I was thinking it would be nice to be able to relate error messages to the documented argument names

or formal arguments?

Borrowing the example from https://docs.racket-lang.org/reference/exns.html?q=directory#%28def._%28%28quote._~23~25kernel%29._raise-argument-error%29%29

(define (feed-machine bits) (if (not (integer? bits)) (raise-argument-error 'feed-machine "integer?" bits) "fed the machine"))

if bad argument is given for bits will produce

feed-machine: contract violation expected: integer? given: ’turkey`

I’d like the error message to instead say

feed-machine: contract violation expected: integer? given: ’turkey argument: bits

I realize it may seem pedantic but when dealing with functions with multiple arguments, it’s helpful to know which argument is bad :slightly_smiling_face:

@samth Here’s a comparison between places and my library on a 64core machine… for places, we already know (as posted on the mailing list) but again:

with loci-dev:

So, hey I am happy. :slightly_smiling_face:

wow..

Also, starting the places takes quite awhile. Each new place past the first 20 takes just slightly longer than the previous one while the processes are launched instantaneously because subprocess is asynchronous and all of them come up pretty much instantaneously.

I will write to the mailing list on this to give a closure to the issue but it’s looking good.

I keep being amazed at how far Racket can take you with just a few hours work. Thursday during the mailing list discussion, I told my wife : hey this library will probably take me a week to write. After I found @mflatt start on places as processes I revised that to 2 days. When I told her today at lunch time that it was working, she couldn’t believe it. I told her… hey, that’s racket for you. :slightly_smiling_face:

Tomorrow I will move my system to using loci-dev so I can dogfood myself.

For now it’s (late) dinner time on this side of the world. See you tomorrow.

thanks @pocmatos for the report, it’s really cool!

I just get my friend to loan me their machine

yeah, I feel pretty promising about this. I have a kind of mess of ocaml code implementing this I’d like rebuild in ocaml

I’m guessing that you’ve noticed that raise-argument-error supports reporting which argument is bad in terms of an argument position, as long as you also supply the other arguments (to include those other argument in the error message, too). But it’s not very convenient. I view the names of formal arguments to be the implementation’s business and not exposed to callers, much like the body of the function. I also think of argument names in documentation as being specific to the documentation, and not something with a run-time instantiation. That is, if I rename the argument in the documentation, I would not expect that to imply an implementation change. And not all arguments have sensible names outside of documentation, such as the arguments to +. So that’s why I’m pushing back on the notion of an argument “name”. But I think an optional “role description” for an argument is sensible and general.

That makes sense and convinces me it’s a bad idea to reply on argument names which is too implementation dependent. An optional “role description” would be nice to have, the current raise-argument-error can be extended to have the extra optional argument instead of creating an entire new variant.