Re: [racket-dev] GNU lightning version
At Wed, 03 Sep 2014 13:07:05 +0400, Yaroslav Tsarko wrote: > are there any > reasons why Racket currently uses very old > version of GNU Lightning? According to sources, Racket 6.1 uses GNU > Lightning version 1.2 which originates from 2004 > [...] > Is it manpower problems (there is nobody who can upgrade this component > in Racket), technical ones or something else? There are a few technical issues, any of which might be addressed by contributing back to Lighting, but mostly it's a question of manpower. We've modified GNU Lighting in various ways. Some of those ways turned out to be uninteresting, and we'd do just as well to re-sync with the latest Lighting. Other changes involved the conventions for register and stack usage, where where re-syncing might be more difficult, and Racket depends on some implementation details instead of treating Lighting as a black box. Some changes should have been wrappers around GNU Lighting, in retrospect, so re-syncing would be good, but it's a lot of work. I don't know GNU Lightning's current stance on jump distances on various platforms, but for Racket, we adapted it to handle a mixture of short jumps (faster when the JIT knows that it will work), long jumps (otherwise), and very long jumps (on x86-64 when the memory allocated for code becomes further apart than fit in 32-bit values). Adding the jump-distance generalizations to 2.0 would take some work, and it's messy enough that I'm not sure the Lighting maintainers would be happy to take it. One other change might be tricky: the x86 build uses both SSE and x87 instructions to support a mixture of flonums and extflonums, and Lighting originally worked with only one or the other --- but that might have changed. > and current version of > GNU Lightning is 2.0 which supports many new back-ends, particularly MIPS. I back-ported ARM support from and almost-2.0 version of Lighting, and that process was relatively easy. I had to know about and adapt Racket's assumptions about Lightning, though. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] variable wrong procedure or structure-type shape error?
At Sat, 30 Aug 2014 10:25:53 -0700, Kevin Forchione wrote: > > On Aug 30, 2014, at 7:09 AM, Matthew Flatt wrote: > > > Just for the record, this is my fault for not incrementing the version > > with a change to the compiler's optimizer. > > > > I thought of the optimization as "local" and having no effect on a > > module's interface to other modules. There's no such thing, though, > > since optimizer-inferred properties of a function's body are exported > > with a function, and those properties can change with most any > > optimizer adjustment. > > > Just to fill in another hole in my swiss-cheese education, what do we > mean by “shape” with regard to procedure/structure type? The term "shape" in the error message isn't meant as any particular, accepted concept outside the optimizer. In this context, "shape" just means information about the value that the optimizer finds worthwhile to track, such as the function's arity and whether it adjusts the continuation-mark stack. > It was the require of a class > that was producing the error, and I’ve gathered that classes are implemented > with structures. It was baffling to my why the module containing the class > compiled without error, but compiling the module requiring it failed. It was > also interesting that the module did compile fine with the latest version, > until I’d tossed the compiled folder in the trash. Running race make on the > top-level file resolved the problem, but I’m wondering why the “run” in > DrRacket didn’t do the same. By default, DrRacket compiles the files that it loads, but it compiles and uses them in "errortrace" mode (the bytecode is kept in a separate subdirectory), so that may have something to do with it. I can't say exactly how it went in your case, but things go wrong in various baroque ways when the optimizer changes and the version number doesn't. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] How to translate DrRacket GUI to another (human) language?
On Sep 5, 2014, at 11:15 AM, Antti Karttunen wrote: > On Fri, Sep 5, 2014 at 5:16 PM, Matthias Felleisen > wrote: >> >> A word of caution about *SL error messages. These messages are synthesized >> from fragments of sentences and then a global rewriter re-arranges them to >> improve their meaning based on work done by Guillaume Marceau, Kathi Fisler >> and Shriram (see SIGCSE 2010). The rewriter catches English phrases at the >> moment; you might be best off checking it out first. >> >> Sorry -- one day we'll get this aspect right -- Matthias >> > > Well, thanks in any case! For the moment we decided to proceed with > the English version. > > By the way, would it be a good idea to create a mailing list for > people who use (or intend to use) DrRacket in teaching, as separate > from an ordinary technical discussion? (I mean the main list.) There is plt-edu, low traffic. populated by educators who teach at many levels but mostly high school (14-18), freshman college. You can sign up for it from the Racket web site. > Here in Finland I know at least our team of three people who have > independently chosen (not knowing each other until quite recently) > DrRacket for teaching programming to (almost) complete beginners (not > CS-students), with encouraging results. Yes, I hear this again and again. We should be proactive and support such larger, special-domain user bases better. > It would be nice to have a forum for sharing specific pedagogical tips > when using DrRacket, with people from all over the world. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] How to translate DrRacket GUI to another (human) language?
On Fri, Sep 5, 2014 at 5:16 PM, Matthias Felleisen wrote: > > A word of caution about *SL error messages. These messages are synthesized > from fragments of sentences and then a global rewriter re-arranges them to > improve their meaning based on work done by Guillaume Marceau, Kathi Fisler > and Shriram (see SIGCSE 2010). The rewriter catches English phrases at the > moment; you might be best off checking it out first. > > Sorry -- one day we'll get this aspect right -- Matthias > Well, thanks in any case! For the moment we decided to proceed with the English version. By the way, would it be a good idea to create a mailing list for people who use (or intend to use) DrRacket in teaching, as separate from an ordinary technical discussion? (I mean the main list.) Here in Finland I know at least our team of three people who have independently chosen (not knowing each other until quite recently) DrRacket for teaching programming to (almost) complete beginners (not CS-students), with encouraging results. It would be nice to have a forum for sharing specific pedagogical tips when using DrRacket, with people from all over the world. Yours, Antti Karttunen _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] How to translate DrRacket GUI to another (human) language?
A word of caution about *SL error messages. These messages are synthesized from fragments of sentences and then a global rewriter re-arranges them to improve their meaning based on work done by Guillaume Marceau, Kathi Fisler and Shriram (see SIGCSE 2010). The rewriter catches English phrases at the moment; you might be best off checking it out first. Sorry -- one day we'll get this aspect right -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
