[racket-users] documentation discovery and navigability (Was: Python's append vs Racket's append and helping novices understand the implications)

[Neil Van Dyke]

Recent Python experience that might inform Racket docs...

I'm recently dusting off my Python skills[1], while switching to Python 
3, so I'm checking documentation for every little thing.


It was a little surprising to me, that the current official Language and 
Standard Library references did not seem very intuitive, compared to 
those of Racket.  The short version is that some of the fragmenting of 
topics seemed unnecessary, and particularly disruptive (e.g., 
documentation would just end before talking about something that had to 
be there, so you'd confirm that you were in the most plausible manual 
and section, then you'd go and start opening links from what you just 
read in tabs).[2]


To try to inform Racket docs from this inspiration/itch, I'm aware that 
there's very limited resources, but, when possible, I'd like to suggest:


* As I've mentioned before, I think it would be good if the Reference 
and Guide were consolidated.  I still find the distinction between the 
two counterproductive, when I go to read up on something, and need to 
keep checking that I'm not missing half of the key information, 
including what I need.  I think this part of the core is a closed world, 
and small enough, for one manual, and I don't understand the schism.


* Consider which of the separate core manuals should be incorporated 
into the main manual, rather than buried somewhere in the huge "wall of 
manuals" list on the documentation page, possibly only discovered 
through haphazard search.  Especially if they're key/central.  (Or, 
alternatively, break up everything, so at least it's more consistent, 
and we always go to the wall of manuals list for any topic.  But 
semi-random fragmentation of now-central core stuff due to evolution or 
historical accident would seem to cost us every time someone needs that 
information.)


* Going forward, with new core documentation being written, try to put 
it in the best place for discovery and core-ness in context (perhaps 
inline as a section of topical material in core manual, or maybe it's a 
chapter of the core manual, or maybe it's a big thing that's part of 
core but really a fringe topic that should be its own doc, or maybe it's 
not core).


* Tutorials... The main core manual can have tutorial-like discussions 
like the current Guide does, in with the topics.  We also want to 
encourage tutorials that are purely redundant with the core manuals in 
the core-specific information they contain, and these can be separate 
and developed in a very distributed community way.  (And, in the 
development of each tutorial, maybe there's a fuzzy sense of the 
distinction between "this part really belongs in the core manual -- 
probably lots of everyone wants to see this when they're looking at that 
topical chapter" and "the rest of this narrative is redundant with the 
core manual, primarily an alternative pedagogic approach for a 
particular audience or side topic, and should be an independent 
tutorial").  I'll group "cheat sheet for moving from language X to 
Racket" in with tutorials, and suggest that they should also be 
redundant with the core manuals in the core-specific info they contain.


* I'd lean towards putting noteworthy performance notes inline with the 
respective topics.  For example, the contiguous sections that contain 
all documentation about hashes (the keyed collection kind) also 
characterize the performance, and might link to alternatives in this 
discussion.  And maybe so very briefly mention that these are used 
similar to particular abstractions in super-popular languages. I 
appreciate one reason not to mention performance in the text that a new 
Racketeer will be looking at is pedagogic (people get tripped-up 
overthinking performance before they've learned basics and idioms), but 
I think we can say a hash get is O(whatever) without crippling newbies 
with analysis paralysis.  However, broader performance optimization 
strategies and tools not specific to, say, hashes, would be its own 
chapter, of course.  (If someone developed a rigorous cost model, even 
that (the eventual Racket engineering documentation, not any separate 
academic paper, nor any tool support) might be inline with the canonical 
topical text, rather than its own separate chapter or manual; I'm not sure.)


Again, resources are tight, and, if a lot of this is not possible even 
if you agree with it, then maybe just consider some gist of these 
suggestions when further work is happening anyway?



[1] Doing Python even for things for which Racket would work even 
better, partly for technical pragmatic reasons (learning ML tools that 
use it for examples, and for a little server tool with minimal 
dependencies), and partly because I briefly considered playing along 
with FAANG hazing of principal engineer applicants.  ("For 
the first new-college-grad step, I need to see whether you can code."  
"Uh, you have my resume, and I know you guys have heard of open source.  
Is 

[racket-users] modules as a data format

[Jack Rosenthal]

Hi Racketeers,

I've got what seems like a common way to use a #lang, make the
#%module-begin provide a certain name and use a local-require to get the
contents. I'm using Jens Axel's urlang and including the compiled
JavaScript in some Xexpressions later on. Here's how I've set up my
#%module-begin for the urlang #lang:

(define-syntax-rule (module-begin body ...)
  (#%plain-module-begin
   (provide the-javascript)
   (define (the-javascript)
 (with-output-to-string
   (λ () (compile #'(urmodule mod body ...)))

Getting the compiled JavaScript is relatively easy...

(let ()
  (local-require "js/test.rkt")
  (the-javascript))

However, attempting to abstract this into a macro is less easy ;). Here
was my first attempt:

(define-syntax-rule (urlang-js modpath)
  (let ()
(local-require (only-in modpath the-javascript))
(the-javascript)))

... later on ...

(urlang-js "js/test.rkt")

; main.rkt:15:11: the-javascript: unbound identifier
;   in: the-javascript
;   context...:
;[common scopes]
;   other binding...:
;local
;#(82760 local) #(82761 intdef) [common scopes]
;   common scopes...:
;#(82611 module) #(82614 module main) #(82766 local) #(82767 intdef)
; [Due to errors, REPL is just module language, requires, and stub definitions]

Oops. (Wasn't even able to (eval (expand #'(urlang-js "js/test.rkt"

Attempted to fix after digging thru docs and finding
syntax-local-introduce:

(define-syntax (urlang-js stx)
  (syntax-case stx ()
[(_ modpath)
 #`(let ()
 #,(syntax-local-introduce
#'(local-require (only-in modpath the-javascript)))
 (the-javascript))]))

Fixed usage within eval, but still no dice introducing urlang-js in
code.

Advice? Is there just a better way of doing this than a #lang maybe?

Thanks,

Jack

-- 
Jack M. Rosenthal
http://jack.rosenth.al

We guarantee that each number is random individually, but we
don't guarantee that more than one of them is random.
-- early PMMLCG vendor

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [racket-users] Python's append vs Racket's append and helping novices understand the implications

[Matthias Felleisen]

Agreed! 



> On Feb 3, 2019, at 4:43 PM, Robby Findler  wrote:
> 
> It seems like a great addition to the performance section of the guide. 
> 
> Robby 
> 
> On Sun, Feb 3, 2019 at 3:35 PM Matthias Felleisen  > wrote:
> 
> 1. I think this is a great start for a generic introduction to data 
> structures. Someone should integrate Jens’s short table: 
> 
>  
> https://stackoverflow.com/questions/27584416/in-racket-what-is-the-advantage-of-lists-over-vectors/27589146#27589146
>  
> 
>  
> 
> 
> 2. I think language-to-language documents serve a different role, but your 
> document could be cited from there. 
> 
> The point of say “From Python to Racket” would be to show how comprehensions 
> translate or how classes work 1-1. And yes, it would also explain that Racket 
> calls something a list that does __not___ at all correspond to a list. 
> 
> The corresponding Java write-up would be quite different again. In that case, 
> we would be dealing with people who might not know more than classes and 
> methods. But they might actually know proper design and might know that it 
> calls for recursion (hidden in classes and interfaces). In Racket, that works 
> even better than in Java. Plus it would need to say something brief about 
> types. 
> 
> And R would be an entirely different story. 
> 
> — Matthias
> 
> 
> 
> 
> 
>> On Feb 2, 2019, at 11:37 PM, Alex Harsanyi > > wrote:
>> 
>> 
>> I put together some notes about available data structures in Racket, with 
>> some performance considerations.  It needs more work, but perhaps it can be 
>> used as a starting point and it can be added to the Racket wiki, if/when 
>> others consider it adequate:
>> 
>> https://gist.github.com/alex-hhh/3cc5690a7f9c74543dab6c11344e6202 
>> 
>> 
>> I didn't write a "Python to Racket" guide, because I don't really know 
>> enough about Python to write such a document, and I also think that a more 
>> generic document is simpler to maintain and can be used by people who come 
>> from other languages as well.
>> 
>> I also tried to keep the document short, the aim being to provide a 
>> competent programmer who is new to Racket with a 5 minute overview to its 
>> data structures and some links to the starting points in the documentation.  
>> We can add things to it, but I think it is better to keep it short rather 
>> than comprehensive in this case -- after all, there is the Racket Guide and 
>> Racket Reference and these documents contain all the details.  Perhaps new 
>> documents can be added to the wiki, exploring other topics in more detail.
>> 
>> I did not mention `ralist` because (1) I have no experience with it, but 
>> more importantly (2) the package is not part of the Racket distribution and 
>> has to be installed separately.  I don't it reflects well on Racket if we 
>> tell people to install a separate package if they want an efficient 
>> container...  I have no experience with `ralist`, but if it is indeed a good 
>> data structure and it has a potentially wide usage, it should be included in 
>> the default Racket installation.
>> 
>> Alex.
>> 
>> On Sunday, February 3, 2019 at 7:00:10 AM UTC+8, Matthias Felleisen wrote:
>> 
>> 
>> Racket needs *you*. Please. 
>> 
>> The proper approach is to have short pages for different language 
>> immigration groups: Python and R come to mind as obvious examples but I am 
>> sure there are others. 
>> 
>> What I mean is we need help and *you* can help. Let me explain it with the 
>> Python example: 
>> 
>> 1. Set up a page (wiki?) called “From Python to Racket” 
>> 
>> 2. Create two sections that are immediately visible from the top: 
>>  
>> — idioms 
>> — performance pitfalls 
>> 
>> 3. In the specific case of Python, the second subsection needs to start with 
>> a subsection on 
>> 
>> — Python Lists aren’t Racket Lists 
>> — then point to data/ralis and show how to transliterate the 
>> loop/append example like this 
>> — optionally also show the more native Racket idiom 
>> 
>> 4. When anyone observers another blog/social media/whatever post on Racket 
>> is slow because I come from Python, 
>> 
>> (a) point the posters to the page  or 
>> (b) if it is a new case, write a section for this example then do 
>> (a) 
>> 
>> 
>> If you want to help advertise Racket to others, this is an excellent way of 
>> helping out. 
>> 
>> Thanks — Matthias 
>> 
>> [[ p.s. For my very first Python program (a couple of days before meeting 
>> with GvR), I used Python’s append and was annoyed beyond belief. ]] 
>> 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop 

Re: [racket-users] Python's append vs Racket's append and helping novices understand the implications

[Robby Findler]

It seems like a great addition to the performance section of the guide.

Robby

On Sun, Feb 3, 2019 at 3:35 PM Matthias Felleisen 
wrote:

>
> 1. I think this is a great start for a generic introduction to data
> structures. Someone should integrate Jens’s short table:
>
>
> https://stackoverflow.com/questions/27584416/in-racket-what-is-the-advantage-of-lists-over-vectors/27589146#27589146
>
>
>
> 2. I think language-to-language documents serve a different role, but your
> document could be cited from there.
>
> The point of say “From Python to Racket” would be to show how
> comprehensions translate or how classes work 1-1. And yes, it would also
> explain that Racket calls something a list that does __not___ at all
> correspond to a list.
>
> The corresponding Java write-up would be quite different again. In that
> case, we would be dealing with people who might not know more than classes
> and methods. But they might actually know proper design and might know that
> it calls for recursion (hidden in classes and interfaces). In Racket, that
> works even better than in Java. Plus it would need to say something brief
> about types.
>
> And R would be an entirely different story.
>
> — Matthias
>
>
>
>
>
> On Feb 2, 2019, at 11:37 PM, Alex Harsanyi  wrote:
>
>
> I put together some notes about available data structures in Racket, with
> some performance considerations.  It needs more work, but perhaps it can be
> used as a starting point and it can be added to the Racket wiki, if/when
> others consider it adequate:
>
> https://gist.github.com/alex-hhh/3cc5690a7f9c74543dab6c11344e6202
>
> I didn't write a "Python to Racket" guide, because I don't really know
> enough about Python to write such a document, and I also think that a more
> generic document is simpler to maintain and can be used by people who come
> from other languages as well.
>
> I also tried to keep the document short, the aim being to provide a
> competent programmer who is new to Racket with a 5 minute overview to its
> data structures and some links to the starting points in the
> documentation.  We can add things to it, but I think it is better to keep
> it short rather than comprehensive in this case -- after all, there is the
> Racket Guide and Racket Reference and these documents contain all the
> details.  Perhaps new documents can be added to the wiki, exploring other
> topics in more detail.
>
> I did not mention `ralist` because (1) I have no experience with it, but
> more importantly (2) the package is not part of the Racket distribution and
> has to be installed separately.  I don't it reflects well on Racket if we
> tell people to install a separate package if they want an efficient
> container...  I have no experience with `ralist`, but if it is indeed a
> good data structure and it has a potentially wide usage, it should be
> included in the default Racket installation.
>
> Alex.
>
> On Sunday, February 3, 2019 at 7:00:10 AM UTC+8, Matthias Felleisen wrote:
>>
>>
>>
>> Racket needs *you*. Please.
>>
>> The proper approach is to have short pages for different language
>> immigration groups: Python and R come to mind as obvious examples but I am
>> sure there are others.
>>
>> What I mean is we need help and *you* can help. Let me explain it with
>> the Python example:
>>
>> 1. Set up a page (wiki?) called “From Python to Racket”
>>
>> 2. Create two sections that are immediately visible from the top:
>>
>> — idioms
>> — performance pitfalls
>>
>> 3. In the specific case of Python, the second subsection needs to start
>> with a subsection on
>>
>> — Python Lists aren’t Racket Lists
>> — then point to data/ralis and show how to transliterate the
>> loop/append example like this
>> — optionally also show the more native Racket idiom
>>
>> 4. When anyone observers another blog/social media/whatever post on
>> Racket is slow because I come from Python,
>>
>> (a) point the posters to the page  or
>> (b) if it is a new case, write a section for this example then do
>> (a)
>>
>>
>> If you want to help advertise Racket to others, this is an excellent way
>> of helping out.
>>
>> Thanks — Matthias
>>
>> [[ p.s. For my very first Python program (a couple of days before meeting
>> with GvR), I used Python’s append and was annoyed beyond belief. ]]
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because 

Re: [racket-users] Python's append vs Racket's append and helping novices understand the implications

[Matthias Felleisen]

1. I think this is a great start for a generic introduction to data structures. 
Someone should integrate Jens’s short table: 

 
https://stackoverflow.com/questions/27584416/in-racket-what-is-the-advantage-of-lists-over-vectors/27589146#27589146
 

 


2. I think language-to-language documents serve a different role, but your 
document could be cited from there. 

The point of say “From Python to Racket” would be to show how comprehensions 
translate or how classes work 1-1. And yes, it would also explain that Racket 
calls something a list that does __not___ at all correspond to a list. 

The corresponding Java write-up would be quite different again. In that case, 
we would be dealing with people who might not know more than classes and 
methods. But they might actually know proper design and might know that it 
calls for recursion (hidden in classes and interfaces). In Racket, that works 
even better than in Java. Plus it would need to say something brief about 
types. 

And R would be an entirely different story. 

— Matthias





> On Feb 2, 2019, at 11:37 PM, Alex Harsanyi  wrote:
> 
> 
> I put together some notes about available data structures in Racket, with 
> some performance considerations.  It needs more work, but perhaps it can be 
> used as a starting point and it can be added to the Racket wiki, if/when 
> others consider it adequate:
> 
> https://gist.github.com/alex-hhh/3cc5690a7f9c74543dab6c11344e6202
> 
> I didn't write a "Python to Racket" guide, because I don't really know enough 
> about Python to write such a document, and I also think that a more generic 
> document is simpler to maintain and can be used by people who come from other 
> languages as well.
> 
> I also tried to keep the document short, the aim being to provide a competent 
> programmer who is new to Racket with a 5 minute overview to its data 
> structures and some links to the starting points in the documentation.  We 
> can add things to it, but I think it is better to keep it short rather than 
> comprehensive in this case -- after all, there is the Racket Guide and Racket 
> Reference and these documents contain all the details.  Perhaps new documents 
> can be added to the wiki, exploring other topics in more detail.
> 
> I did not mention `ralist` because (1) I have no experience with it, but more 
> importantly (2) the package is not part of the Racket distribution and has to 
> be installed separately.  I don't it reflects well on Racket if we tell 
> people to install a separate package if they want an efficient container...  
> I have no experience with `ralist`, but if it is indeed a good data structure 
> and it has a potentially wide usage, it should be included in the default 
> Racket installation.
> 
> Alex.
> 
> On Sunday, February 3, 2019 at 7:00:10 AM UTC+8, Matthias Felleisen wrote:
> 
> 
> Racket needs *you*. Please. 
> 
> The proper approach is to have short pages for different language immigration 
> groups: Python and R come to mind as obvious examples but I am sure there are 
> others. 
> 
> What I mean is we need help and *you* can help. Let me explain it with the 
> Python example: 
> 
> 1. Set up a page (wiki?) called “From Python to Racket” 
> 
> 2. Create two sections that are immediately visible from the top: 
>  
> — idioms 
> — performance pitfalls 
> 
> 3. In the specific case of Python, the second subsection needs to start with 
> a subsection on 
> 
> — Python Lists aren’t Racket Lists 
> — then point to data/ralis and show how to transliterate the 
> loop/append example like this 
> — optionally also show the more native Racket idiom 
> 
> 4. When anyone observers another blog/social media/whatever post on Racket is 
> slow because I come from Python, 
> 
> (a) point the posters to the page  or 
> (b) if it is a new case, write a section for this example then do (a) 
> 
> 
> If you want to help advertise Racket to others, this is an excellent way of 
> helping out. 
> 
> Thanks — Matthias 
> 
> [[ p.s. For my very first Python program (a couple of days before meeting 
> with GvR), I used Python’s append and was annoyed beyond belief. ]] 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit 

Re: [racket-users] Quickscript error on first startup of Racket 7.2

[Robby Findler]

On Sun, Feb 3, 2019 at 11:50 AM Laurent  wrote:

> I've pushed a repair. It should be integrated with the next racket nightly
> release I suppose.
>
> The fix is to check the compiled version of all scripts in the library,
> and if it differs from the current racket version it gets recompiled. The
> bonus is that scripts that have not been compiled yet will now be, which
> means faster loading time when triggering them.
>
> The caveat is that dependencies are not recompiled. This means that if a
> script depends on a package/collection that hasn't been migrated/updated
> yet, an error may be displayed on DrRacket startup (but appart from this
> script DrRacket should still work fine).
>

Can this error be caught and captioned with a better message or, even
better, perhaps be integrated somehow into quickscript? (Maybe putting
something into the menu or some other place somehow?)


> Feedback more than welcome.
>
> @Robby: I've tested this manually, by installing an old version of racket,
> and compiling scripts with the old one while running the new version of
> drracket, but I'm not sure how to automate this properly (as in "write a
> portable test file"). Have you done something like this before?
>

Maybe save an old compiled file, putting it into place and then starting up
drr the way that other test suites start it up, and checking that it starts
up successfully?

Robbg


>
> On Fri, Feb 1, 2019 at 1:37 PM Laurent  wrote:
>
>> Okay then, I'll work on a fix tomorrow.
>>
>> On Fri, Feb 1, 2019 at 1:23 PM Robby Findler 
>> wrote:
>>
>>> I can't say concretely what will go wrong I am sorry to say. There are
>>> just a number of moving parts and I can't quite see how they will fail to
>>> fit together. I am just basing this on my vague, holistic understanding of
>>> how things work currently. (There are no places where on set of sources is
>>> used with multiple versions in the standard distribution and nontrivial
>>> work has gone into making that case work out and maintain that invariant.)
>>>
>>> In other words, go for it! We have a fallback if this don't work out. :)
>>>
>>> Robby
>>>
>>> On Fri, Feb 1, 2019 at 7:01 AM Laurent  wrote:
>>>
 On Fri, Feb 1, 2019 at 11:30 AM Robby Findler <
 ro...@eecs.northwestern.edu> wrote:

> My feeling is that our compilation infrastructure isn't really set up
> to work like that currently. In general things will probably be smoother 
> if
> there is only the expectation that a given set of files is used with only
> one version at a time.
>
> It is possible that someone may use multiple versions of DrRacket on
> their computer switching between them or even having them open at the same
> time.
>

 Frankly, for any application, if one has multiple versions open at the
 same time and things go wrong, I don't see how one can blame the developers
 with a straight face—the one legitimate case is probably when you're one of
 the developers yourself.

 If you want to use several versions but not at the same time (which is
 also asking for trouble in any case), then recompilation on startup should
 work nicely anyway, just requiring a little more time. Copying the same
 scripts in different folders will very likely mean divergence of source at
 some point and likely frustration for the user.

 Or am I missing something?


>
> Robby
>
> On Fri, Feb 1, 2019 at 4:12 AM Laurent 
> wrote:
>
>> Thanks for bringing this up.
>>
>> Indeed the compile option from the quickscript menu should work, but
>> it's not ideal.
>>
>> I'm not a big fan of the copy option. (To me that sounds like asking
>> for trouble, but I may be wrong.)
>>
>> A nicer solution may be to simply check if the scripts are compiled
>> with the current version, and if not just silently compile them on 
>> DrRacket
>> startup? The user could also be querried if that's better.
>>
>> On Thu, Jan 31, 2019, 23:02 Greg Trzeciak >
>>> As long as the user-scripts won't be lost (i.e. the scripts will be
>>> copied over) it sounds OK.
>>>
>>> On Thursday, January 31, 2019 at 10:42:08 PM UTC+1, Robby Findler
>>> wrote:

 Probably it is best if quickscript (either silently or after
 asking)
 copied scripts from a version-specific directory to a new
 (version-specific) one, much like how the pkg system works.

 Robby

 On Thu, Jan 31, 2019 at 3:38 PM Greg Trzeciak 
 wrote:
 >
 > I had quickscript already installed when upgrading Racket.
 >
 > On DrRacket startup I got the following error:
 >
 > Error in script file "run-in-interactions.rkt":
 read-compiled-linklet: version mismatch
 >   expected: "7.2"
 >   found: "6.90.0.24"
 >   in:
 

Re: [racket-users] Quickscript error on first startup of Racket 7.2

[Laurent]

I've pushed a repair. It should be integrated with the next racket nightly
release I suppose.

The fix is to check the compiled version of all scripts in the library, and
if it differs from the current racket version it gets recompiled. The bonus
is that scripts that have not been compiled yet will now be, which means
faster loading time when triggering them.

The caveat is that dependencies are not recompiled. This means that if a
script depends on a package/collection that hasn't been migrated/updated
yet, an error may be displayed on DrRacket startup (but appart from this
script DrRacket should still work fine).

Feedback more than welcome.

@Robby: I've tested this manually, by installing an old version of racket,
and compiling scripts with the old one while running the new version of
drracket, but I'm not sure how to automate this properly (as in "write a
portable test file"). Have you done something like this before?


On Fri, Feb 1, 2019 at 1:37 PM Laurent  wrote:

> Okay then, I'll work on a fix tomorrow.
>
> On Fri, Feb 1, 2019 at 1:23 PM Robby Findler 
> wrote:
>
>> I can't say concretely what will go wrong I am sorry to say. There are
>> just a number of moving parts and I can't quite see how they will fail to
>> fit together. I am just basing this on my vague, holistic understanding of
>> how things work currently. (There are no places where on set of sources is
>> used with multiple versions in the standard distribution and nontrivial
>> work has gone into making that case work out and maintain that invariant.)
>>
>> In other words, go for it! We have a fallback if this don't work out. :)
>>
>> Robby
>>
>> On Fri, Feb 1, 2019 at 7:01 AM Laurent  wrote:
>>
>>> On Fri, Feb 1, 2019 at 11:30 AM Robby Findler <
>>> ro...@eecs.northwestern.edu> wrote:
>>>
 My feeling is that our compilation infrastructure isn't really set up
 to work like that currently. In general things will probably be smoother if
 there is only the expectation that a given set of files is used with only
 one version at a time.

 It is possible that someone may use multiple versions of DrRacket on
 their computer switching between them or even having them open at the same
 time.

>>>
>>> Frankly, for any application, if one has multiple versions open at the
>>> same time and things go wrong, I don't see how one can blame the developers
>>> with a straight face—the one legitimate case is probably when you're one of
>>> the developers yourself.
>>>
>>> If you want to use several versions but not at the same time (which is
>>> also asking for trouble in any case), then recompilation on startup should
>>> work nicely anyway, just requiring a little more time. Copying the same
>>> scripts in different folders will very likely mean divergence of source at
>>> some point and likely frustration for the user.
>>>
>>> Or am I missing something?
>>>
>>>

 Robby

 On Fri, Feb 1, 2019 at 4:12 AM Laurent 
 wrote:

> Thanks for bringing this up.
>
> Indeed the compile option from the quickscript menu should work, but
> it's not ideal.
>
> I'm not a big fan of the copy option. (To me that sounds like asking
> for trouble, but I may be wrong.)
>
> A nicer solution may be to simply check if the scripts are compiled
> with the current version, and if not just silently compile them on 
> DrRacket
> startup? The user could also be querried if that's better.
>
> On Thu, Jan 31, 2019, 23:02 Greg Trzeciak 
>> As long as the user-scripts won't be lost (i.e. the scripts will be
>> copied over) it sounds OK.
>>
>> On Thursday, January 31, 2019 at 10:42:08 PM UTC+1, Robby Findler
>> wrote:
>>>
>>> Probably it is best if quickscript (either silently or after asking)
>>> copied scripts from a version-specific directory to a new
>>> (version-specific) one, much like how the pkg system works.
>>>
>>> Robby
>>>
>>> On Thu, Jan 31, 2019 at 3:38 PM Greg Trzeciak 
>>> wrote:
>>> >
>>> > I had quickscript already installed when upgrading Racket.
>>> >
>>> > On DrRacket startup I got the following error:
>>> >
>>> > Error in script file "run-in-interactions.rkt":
>>> read-compiled-linklet: version mismatch
>>> >   expected: "7.2"
>>> >   found: "6.90.0.24"
>>> >   in:
>>> C:\Users\Myself\AppData\Roaming\Racket\quickscript\user-scripts\compiled\run-in-interactions_rkt.zo
>>>
>>> >
>>> > After closing the message box DrRacket is opening with no problems
>>> >
>>> > Deleting compiled folder removes the error on the next start up
>>> (and so would probably running "Compile Scripts and  reload" from Script
>>> menu).
>>> > But since quickscript is now part of DrRacket - the error may
>>> reappear in the next upgrades since it looks like user-scripts is not
>>> recompiled during upgrade.
>>> >
>>> > G.

[racket-users] Re: From Guido to Matthias (was: Python's append vs Racket's append and helping novices understand the implications)

[Laurent]

Ouch!! :-D

On Sun, Feb 3, 2019 at 3:40 PM Matthias Felleisen 
wrote:

>
>
> On Feb 3, 2019, at 10:12 AM, Laurent  wrote:
>
> When was that and what was the outcome of this meeting?
>
>
>
> Nothing. It was a waste of my time. — Matthias
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: "raco test" causes my reader to fail on carriage return (but newline works)

[Ryan Kramer]

Progress! Either rebooting, upgrading to 7.2, or something else caused 
DrRacket to start failing in the same way that raco does*. Now it feels 
like a normal problem I can solve using my normal techniques (of scattering 
printlns everywhere).

(* I was wrong when I said that "raco setup" was working - it wasn't.)

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: From Guido to Matthias (was: Python's append vs Racket's append and helping novices understand the implications)

[Matthias Felleisen]

> On Feb 3, 2019, at 10:12 AM, Laurent  wrote:
> 
> When was that and what was the outcome of this meeting?


Nothing. It was a waste of my time. — Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] From Guido to Matthias (was: Python's append vs Racket's append and helping novices understand the implications)

[Laurent]

Now you just peaked my curiosity!

When was that and what was the outcome of this meeting?

On Sat, Feb 2, 2019 at 11:00 PM Matthias Felleisen 
wrote:

>
> [[ p.s. For my very first Python program (a couple of days before meeting
> with GvR), I used Python’s append and was annoyed beyond belief. ]]
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: [racket] Typed racket and keywords

[hashim muqtadir]

> as what I was trying to do was produce a typed version of Greg 
Hendershott's "keyword structs" (
https://www.greghendershott.com/2015/07/keyword-structs-revisited.html )

Sorry, I pointed to the wrong thing. The procedure I was re-implementing 
was hash->struct/kw from 
https://github.com/dstorrs/racket-dstorrs-libs/blob/master/struct.rkt

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: [racket] Typed racket and keywords

[hashim muqtadir]

I found this topic when searching around for something about keyword-apply 
and typed racket, as what I was trying to do was produce a typed version of 
Greg Hendershott's "keyword structs" 
(https://www.greghendershott.com/2015/07/keyword-structs-revisited.html ) 
and I was getting an error saying there's no such thing as keyword-apply.

So I suppose there isn't. Let's add that info in the "Caveats and 
Limitations" part of the guide. Or maybe mention this in the part of the 
reference that says typed/racket reprovides everything that racket has.

Or, maybe it's now easier to add it in? I wish there were a guide to 
contributing to typed racket, though I fear I might be missing a lot of 
prerequisite knowledge even if there were one.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: performance: Racket vs Julia

[Gour]

On Sat, 2 Feb 2019 18:10:31 -0500
Matthias Felleisen 
wrote:

> It is rare that I have to somewhat-contradict Matthew here, but so it
> goes. 

:-)

> Use Racket for what you have in mind. It’s obviously the superior
> language :-) 

That makes the deal. Thank you very much for your input as well as work done on
Racket!


Sincerely,
Gour


-- 
But for one who takes pleasure in the self, whose human life
is one of self-realization, and who is satisfied in the self only,
fully satiated — for him there is no duty.


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: performance: Racket vs Julia

[Gour]

On Sat, 2 Feb 2019 18:24:47 -0500
Neil Van Dyke  wrote:

> Yes, I did another look for Racket last year, and desktop GUI toolkit
> options generally seem to have have actually gotten fewer and worse
> since the move of most of the money to Web and handheld apps.

Yes, very sad. :-(

> We need to advertise this selling point for Racket: "Our syntax is
> not too strange!" :)

Maybe it's, for some, strange, but, otoh, it is simple and I always appreciate
simplicity as general value. :-)

> What I've done recently, as aggregations of existing components, for
> a retro smartphone UI, seemed mostly straightforward (and in this
> case was mostly a kind of coding that one can do for hours without
> having to think hard, so maybe it's a relaxing evening after a day of
> intense high-stakes software engineering :) (unreleased, for now)
> https://www.neilvandyke.org/postmarketos/

This sounds encouraging!

Sincerely,
Gour

-- 
The humble sages, by virtue of true knowledge, see with equal
vision a learned and gentle brāhmana, a cow, an elephant, a dog
and a dog-eater.


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Python's append vs Racket's append and helping novices understand the implications

[Robby Findler]

This is very nice!

Robby

On Sat, Feb 2, 2019 at 10:37 PM Alex Harsanyi 
wrote:

>
> I put together some notes about available data structures in Racket, with
> some performance considerations.  It needs more work, but perhaps it can be
> used as a starting point and it can be added to the Racket wiki, if/when
> others consider it adequate:
>
> https://gist.github.com/alex-hhh/3cc5690a7f9c74543dab6c11344e6202
>
> I didn't write a "Python to Racket" guide, because I don't really know
> enough about Python to write such a document, and I also think that a more
> generic document is simpler to maintain and can be used by people who come
> from other languages as well.
>
> I also tried to keep the document short, the aim being to provide a
> competent programmer who is new to Racket with a 5 minute overview to its
> data structures and some links to the starting points in the
> documentation.  We can add things to it, but I think it is better to keep
> it short rather than comprehensive in this case -- after all, there is the
> Racket Guide and Racket Reference and these documents contain all the
> details.  Perhaps new documents can be added to the wiki, exploring other
> topics in more detail.
>
> I did not mention `ralist` because (1) I have no experience with it, but
> more importantly (2) the package is not part of the Racket distribution and
> has to be installed separately.  I don't it reflects well on Racket if we
> tell people to install a separate package if they want an efficient
> container...  I have no experience with `ralist`, but if it is indeed a
> good data structure and it has a potentially wide usage, it should be
> included in the default Racket installation.
>
> Alex.
>
> On Sunday, February 3, 2019 at 7:00:10 AM UTC+8, Matthias Felleisen wrote:
>>
>>
>>
>> Racket needs *you*. Please.
>>
>> The proper approach is to have short pages for different language
>> immigration groups: Python and R come to mind as obvious examples but I am
>> sure there are others.
>>
>> What I mean is we need help and *you* can help. Let me explain it with
>> the Python example:
>>
>> 1. Set up a page (wiki?) called “From Python to Racket”
>>
>> 2. Create two sections that are immediately visible from the top:
>>
>> — idioms
>> — performance pitfalls
>>
>> 3. In the specific case of Python, the second subsection needs to start
>> with a subsection on
>>
>> — Python Lists aren’t Racket Lists
>> — then point to data/ralis and show how to transliterate the
>> loop/append example like this
>> — optionally also show the more native Racket idiom
>>
>> 4. When anyone observers another blog/social media/whatever post on
>> Racket is slow because I come from Python,
>>
>> (a) point the posters to the page  or
>> (b) if it is a new case, write a section for this example then do
>> (a)
>>
>>
>> If you want to help advertise Racket to others, this is an excellent way
>> of helping out.
>>
>> Thanks — Matthias
>>
>> [[ p.s. For my very first Python program (a couple of days before meeting
>> with GvR), I used Python’s append and was annoyed beyond belief. ]]
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: performance: Racket vs Julia

[Konrad Hinsen]

Matthias Felleisen  writes:

> It is rare that I have to somewhat-contradict Matthew here, but so it goes. 
>
> One of my colleagues, Jan Vitek, has studied Julia with a special
> focus on performance. As many have said, Julia is good at numerics
> because its compiler can specialize certain cases really well. More

I'd really like to see something like Julia as a special-purpose
language in a general-purpose language ecosystem such as Racket.

Having to choose between numerical performance and good support for
non-numerical stuff such as user interfaces is a real pain. Given that
performance almost always trumps everything else in number crunching,
the result is that number crunching software is always bad from every
point of view other than performance.

Konrad.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[Konrad Hinsen]

David Storrs  writes:

> What projects have y'all done where XML was the best choice for a
> reason other than "because we needed to interoperate with a service
> that required XML"?

This:

   https://mosaic-data-model.github.io/

and this:

   https://github.com/khinsen/leibniz/

In both cases, the motivation was to facilitate access to the data for
as many software developers as possible. There are good XML support
libraries for most programming languages, even Fortran.

The other candidates in such circumstances are JSON and YAML, but you
get a lot more structure for free with XML than with JSON, while
avoiding the enormous complexity of YAML. I also found some utility in
schemas and schema-based validation tools, although that universe looks
heavily overengineered to me. Still, it's work done by others that I
don't have to repeat myself.

I think someone suggested s-expressions here. That would be a fine
option, if there were better support for it in non-Lisp languages.

> On the other hand, XML is extremely heavyweight, thereby slowing
> parsing and transmission as well as making the data less
> human-readable.

Compared to what? Special-purpose data format? Design your own language,
write you own parsers, working at the character level? I don't write
software in assembly for good reasons, and for the same reasons I want
higher-level data formats than just character streams.

Konrad.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Python's append vs Racket's append and helping novices understand the implications

[Zelphir Kaltstahl]

I think having such migration pages for people coming from other
languages is a good idea. Maybe also should include basic programming
knowledge such as "a single linked list is not a vector", but then where
to begin? If such page says that some operations are slower on Racket
lists (append), then best to put also an explanation why this is not
necessarily a bad thing (because the lists are used in a certain way,
where such operations are avoided mostly and otherwise we use
differently named data structures) or in what situations some operations
are faster. Otherwise people might simply go and think: "Oh my, why
don't they simply use lists like in Python?" The page needs to tell
people: "What you found in Python, you also have in Racket, just use
data structure xyz."


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Python's append vs Racket's append and helping novices understand the implications

[Jens Axel Søgaard]

FWIW here is an overview over data structures in Racket:

https://stackoverflow.com/questions/27584416/in-racket-what-is-the-advantage-of-lists-over-vectors/27589146#27589146

/Jens Axel


Den søn. 3. feb. 2019 kl. 05.37 skrev Alex Harsanyi :

>
> I put together some notes about available data structures in Racket, with
> some performance considerations.  It needs more work, but perhaps it can be
> used as a starting point and it can be added to the Racket wiki, if/when
> others consider it adequate:
>
> https://gist.github.com/alex-hhh/3cc5690a7f9c74543dab6c11344e6202
>
> I didn't write a "Python to Racket" guide, because I don't really know
> enough about Python to write such a document, and I also think that a more
> generic document is simpler to maintain and can be used by people who come
> from other languages as well.
>
> I also tried to keep the document short, the aim being to provide a
> competent programmer who is new to Racket with a 5 minute overview to its
> data structures and some links to the starting points in the
> documentation.  We can add things to it, but I think it is better to keep
> it short rather than comprehensive in this case -- after all, there is the
> Racket Guide and Racket Reference and these documents contain all the
> details.  Perhaps new documents can be added to the wiki, exploring other
> topics in more detail.
>
> I did not mention `ralist` because (1) I have no experience with it, but
> more importantly (2) the package is not part of the Racket distribution and
> has to be installed separately.  I don't it reflects well on Racket if we
> tell people to install a separate package if they want an efficient
> container...  I have no experience with `ralist`, but if it is indeed a
> good data structure and it has a potentially wide usage, it should be
> included in the default Racket installation.
>
> Alex.
>
> On Sunday, February 3, 2019 at 7:00:10 AM UTC+8, Matthias Felleisen wrote:
>>
>>
>>
>> Racket needs *you*. Please.
>>
>> The proper approach is to have short pages for different language
>> immigration groups: Python and R come to mind as obvious examples but I am
>> sure there are others.
>>
>> What I mean is we need help and *you* can help. Let me explain it with
>> the Python example:
>>
>> 1. Set up a page (wiki?) called “From Python to Racket”
>>
>> 2. Create two sections that are immediately visible from the top:
>>
>> — idioms
>> — performance pitfalls
>>
>> 3. In the specific case of Python, the second subsection needs to start
>> with a subsection on
>>
>> — Python Lists aren’t Racket Lists
>> — then point to data/ralis and show how to transliterate the
>> loop/append example like this
>> — optionally also show the more native Racket idiom
>>
>> 4. When anyone observers another blog/social media/whatever post on
>> Racket is slow because I come from Python,
>>
>> (a) point the posters to the page  or
>> (b) if it is a new case, write a section for this example then do
>> (a)
>>
>>
>> If you want to help advertise Racket to others, this is an excellent way
>> of helping out.
>>
>> Thanks — Matthias
>>
>> [[ p.s. For my very first Python program (a couple of days before meeting
>> with GvR), I used Python’s append and was annoyed beyond belief. ]]
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
-- 
Jens Axel Søgaard

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.