Am making some sort of newbie mistake here with a hash but its making me a little crazy. I have a hasheq in a struct, but when I try to call hash-ref on a key in that hash I get an error. But the key exists -> http://pasterack.org/pastes/63874

My first guess is that the two strings "Server" (the first being the hash key and the other the search term to hash-ref) are equal? but not eq?.

yeppp… switching to a plain hash solves the issue….

!@#$

Hello racketeers :)

I have an issue, I need your help with. I’m trying to isolate the minimal racket from the main github distribution and the makefile is a definite issue, trying to setup the Travis tests but those fail ’cos of unmodified make file.

https://github.com/abhi18av/minimal-racket

I’d love to work on racket internals)

I don’t understand your goal. Minimal Racket already lives in its own directory (https://github.com/racket/racket/tree/master/racket/src). Also, what is the problem with “unmodified Makefile” and TravisCI?

@abhi18av roughly you just need to delete the pkgs directory to have only minimal racket

and then just make base will build effectively minimal racket with the regular makefile

@samth Right. But what if I need to integrate it with .travis.yml with tests.

Are there c-source level tests I can benchmark against, if I make changes.

@abhi18av what are your goals here?

to run the most minimal tests, see the racket-test-core pkg

@samth , actually I’m trying to figure out how the nanopass compiler integrates and how to modernize the c codebase.

@abhi18av which nanopass compiler? and why would this require changing the repository?

@samth Mm, the one that Alan keep and Dybvig worked on, I found about racket plans for a new compiler in “inside-racket” videos.

@abhi18av well, @leif has been working on a new version of the racket compiler using nanopass, but the compiler that Keep and Dybvig describe is for Chez Scheme, not part of racket

and I don’t think changing the repository is a good way of going about this

there’s a reason that those things are in the same repository

@samth and @leafac yes but lately I’ve become really interested in compilers and VMs.

Actually, I need the minimal subset of racket to work with and then port it to, maybe rust or something ( like remacs project) as a learning experience.

I know typed racket and all other langs build upon this one, so the subset and the base machinery is interesting that way.

right, but the minimal core language is what’s implemented by racket/racket repo

Mm, how about gracket. I’d like remove that as well.

gracket is primarily implemented in the racket/gui repo

So, what you’re saying is that this is already bare minimum?

yes

Hmmm, interesting! I spent the last two days trying to chip things away.

Btw @samth , the makefile is a bit difficult for me - is here other format I can convert it to?

no, not really

Could you tell me whats the plan regarding the c-codebase?

I know that chez has a minimal approach towards C but Guile is more alike

@samth , there’s a lot of mzscheme etc in the repo as well in codebase - that necessary too?

The plan is to gradually move things from C to Racket

you can see some progress on this in the linklet branch of mflatt/racket

Yes, I’ve been testing in that branch itself.

But, still some parts would still be kept in C right?

The GC etc

the use of mzscheme is historical

most likely that will stay in C for a long time

Okay, so I’ve reframed my question. What do I need to remove to have racket build for ubuntu 14.04 – 3m GC only - minimal

Without dealing with the source files as of yet, and the entire lightning folder can be chipped as well - changes like these.

Senhora is not used by default, like CGC right

why do you need to remove source files?

In general, just run make base and it will build just the core of racket

Can someone help me understand why I don’t see my ’@%expand-envexpand when used inside my@%letrec-parser`? http://pasterack.org/;((%22k%22%20.%20%22(288279%201%2011142559)%22))

hmm looks like i broke pasterack :disappointed:

The core of my question is: "Is it okay to call a syntax-parser from another syntax-parser? it seems to work sometimes but other times it doesn’t.. I know i must be doing something different, but its not clear what.

@jerryj: The answer to your question is “yes”, without caveats. syntax-parser is just a macro for a procedure of one argument that uses syntax-parse, and syntax-parse is just a very fancy pattern-matching construct for syntax objects.

@lexi.lambda Thanks for the confirmation, i guess i need to massage how I have ordered things :]

Try posting your code again? Sometimes you have to wait for pasterack to redirect.

i’ll pop it to a github gist or something. are fragments ok? i don’t know how much context is needed (thank you!!)

actually i’ll just push the whole project to my gh

@lexi.lambda here is the mess: https://github.com/jerry-james/iswim. The macros are in main.rkt, the input file i’m fighting with is under private/test.rkt. I’m trying to make a letrec macro that will build up a global environment and give that global-env to each variable in the letrec.

stuff you’ll see in the code doesn’t make that end-goal obvious, i just tried to get it into a somewhat presentable state..

Oh, Also, my REAL goal is to put a nice front-end onto the redex langs i’m building. I want some facilities for building up environments, i’d like to be able to use a (let ...) instead of manually building up lambdas, etc.

oh no, is it that ..._1 means something different in syntax-parse than it does in redex? :[

could you try and produce a more minimal example?

sure thing!

@lexi.lambda I removed a lot of extra code, so now it just shows the macro not being expanded. the test.rkt contains (letrec ([x 2] [y 3]) (addem x)), which yields '((((letrec ((x 2) (y 3)) (addem x)) (@%expand-env (letrec ((x 2) (y 3)) (addem x)))) mt))

jerryj

change #:literals to #:datum-literals?

@thinkmoore no dice :disappointed:

does DrRacket show a binding arrow for @%expand-env in the module begin macro?

yes, but its the purple ’?’ arrow

oh, try (apply-reduction-relation* cek (term ((,form ,(@%expand-env form)) mt)))

term is a quasiquote

(sorry if that doesn’t work either…. trying to debug from code inspection…)

@thinkmoore my goodness, that certainly did the trick. i’m kind of astonished though, because i didn’t think you could use , inside a #'(...) expression.

i thought you had to use #,

the , is to escape the term, not the syntax-quote

i think i must have some deep misunderstanding about something here :disappointed:

hmm..

there are multiple types of quoting/unquoting. #, works with #`

, works with `

and term is basically a `

OH

wow. okay, so that brings it into crystal clarity

thank you @thinkmoore!

@lexi.lambda thank you, too! i’d have never gotten this far without learning how pieces fit together from your racket-tulip project.

SEwPR question, In section 6.4 Why does the cek5 reduction relation drop the environment? is that a typo? edit: nevermind, I think i just misunderstood how to create a recursive environment

@florence: I have another errortrace question. Can you explain to me why the (die!) expression is not included in the errortrace for the following code, but the (error ...) and (execute-thunk ...) expressions are? #lang racket (define (good) (void)) (define (die!) (error 'die! "died")) (define (execute-thunk proc) (void (proc))) (execute-thunk (thunk (good) (good) (die!) (good)))

@lexi.lambda I’m not sure, but if I wrap the body of die! in a void it shows up… So yeah I don’t really know what’s going on there, sorry

@florence @lexi.lambda isn’t it just that the error is in tail position wrt die?

@florence @samth I am probably totally misunderstanding how errortrace works, but why would the error being in tail position change whether or not (die!) is annotated, since that expression is not in tail position?

My extremely rudimentary understanding of errortrace is that it just inserts a bunch of with-continuation-mark forms all over the program, in application positions, using the source locations of the expanded syntax objects, then changes the error handler to put the information attached to those continuation marks in the error message.

There must be something more complex going on, though, right? Since the expression in with-continuation-mark is in tail position, but errortrace is definitely impacted by whether or not expressions are in tail position.

After playing with continuation marks a bit and reading the section of the documentation on the evaluation model, I think I sort of understand. Continuation marks are attached to continuation frames, but expressions evaluated in tail position replace the enclosing continuation frame, so the mark gets lost.