Re: [racket-users] Detecting mouse events on top of picts?
On 6/7/2016 3:40 PM, David Christiansen wrote: > Understood. Is it possible to define a region to represent the > clickable areas? This is the way I would do it if possible. > > I haven't done much GUI programming in Racket, so I don't know exactly > what it can do, but in, e.g., Windows GDI you can create a region > directly from a binary (1-bit depth) bitmap [and a bitmap of any depth > can be converted to a binary bitmap]. Set (1) pixels in the bitmap will > be included in the region and unset (0) pixels will be excluded. I don't know of a way to do this, other than what I've been doing with an off-screen buffer for each mouse-sensitive pict. But thanks! /David Looking at the docs for region%, Racket doesn't have a simple way to do this - it still could be done by force and might not be that slow depending on the complexity of the "scene" in the image. If you're familiar with image processing, the basic idea is recursive "blob" identification. I saw in your reply to Matthias that you are "drawing" the pictures into an offscreen bitmap. I know that word "drawing" is overloaded: did you mean you loaded a bitmap (from a file?) and made an offscreen copy, or that you are composing the image with pen/brush. Reason I ask is that if you are composing, constructing a corresponding region% might be relatively easy. George -- 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] Detecting mouse events on top of picts?
Apologies, I was writing this response off line while I was reading your message and as i finished reading yours, I realized your problem was deeper. And apologies for wasting band width. > On Jun 7, 2016, at 3:39 PM, David Christiansen > wrote: > >> Why don’t you check the location of the mouse movement? The coordinates are >> close enough. > > I do check the location of the mouse movement to find a canvas location. > What I was looking for a smarter way to do was to check whether or not > that particular pixel was drawn by a particular pict that has previously > been displayed in the canvas. > > My best approach thus far is to draw the pict into a bitmap, off-screen, > and see if it the corresponding pixel has been modified. I was hoping > that someone knew a smarter way, perhaps in a part of the GUI API that I > had not found, but it doesn't seem to be the case. > > In any case, my current solution is working well enough for now. > > /David > -- 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] define-serializable-cstruct with versions?
Inlined structs are the common case in our application. So the only feasible way I see would be to change the serialization protocol. But this could have a severe impact on the performance (even in the case the versions of the serialized and actual structs are the same) compared to the currently implemented direct conversion to a byte-string of a (arbitrarily deeply nested) inlined struct field. Most important would be to efficiently code struct fields which “inline” arrays of structs. Berthold > On 07 Jun 2016, at 18:15, Matthew Flatt wrote: > > Sorry --- reading through your message one more time, I think I > understand what you're saying. My example involved pointers to > structures, and you're noting that *inlined* structures create a > problem. > > One possibility is to treat a change to `_pond` as a change to > `_forest`, too, and introduce a new version of `_forest`. Or, as you > say, we could change the serialization protocol. Maybe it depends on > how common you expect this case to be. > > At Tue, 7 Jun 2016 17:14:54 +0200, Berthold Bäuml wrote: >> Sorry, I did not think this through completely. Serialization of cstructs, >> as >> it is currently implemented, loses all “sub-structure” for non-pointer >> content, correct? >> >> But wouldn’t because of this lost sub-structure your alternative >> compatibility >> protocol also fail when it comes to hierarchically embedded structs where >> deep >> down in the hierarchy a new version of a struct should be used? >> >> >> (define-serializable-cstruct _pond ([depth _float])) >> (define-serializable-cstruct _forrest ([a_pond _pond])) >> >> and then a new version: >> (define-serializable-cstruct _old-pond ([depth _float])) >> (define-serializable-cstruct _pond ([num-fish _int] >> [depth _float]) >> >> (define-serializable-cstruct _forrest ([a_pond _pond])) >> >> So, the version of _forrest does not change and, hence, there is no way to >> deserialize the correct, new version of the _pond. >> >> I think this could only be resolved by changing the serialization so that it >> keeps all relevant information also for non-pointer content. >> >> Berthold >>> On 06 Jun 2016, at 19:22, Matthew Flatt wrote: >>> >>> Yes, but I think a different protocol will be needed than for >>> `serializable-struct`. >>> >>> With >>> >>> (serializable-struct pond (depth)) >>> >>> it's clear that the deserializer receives a single value for the single >>> field (or, more generally, N values for N fields). So, it's clear how >>> to make a compatibility deserialization function: >>> >>> (serializable-struct/versions pond 1 (num-fish depth) >>> ([0 (lambda (d) (pond 0 d)) >>> (lambda () )])) >>> >>> With >>> >>> (define-serializable-cstruct _pond ([depth _float])) >>> >>> the deserializer internally deals with a byte-string representation of >>> non-pointer content plus a structured representation of pointer >>> content. We probably don't want to expose those details, and you don't >>> want to deal with them. >>> >>> An alternative it to make the compatibility protocol work in terms of a >>> separate cstruct declaration: >>> >>> (define-serializable-cstruct _old-pond ([depth _float])) >>> >>> (define-serializable-cstruct _pond ([num-fish _int] >>>[depth _float]) >>> #:version 1 >>> #:other-versions ([0 deserialize-chain:cstruct:old-pond >>> (lambda (op) >>> (make-pond 0 (old-pond-depth op))) >>> (lambda () )])) >>> >>> That is, compatibility deserialization is based on a reference to >>> deserialization information for a cstruct that has the same shape as >>> the old version, plus converters from instances of the old shape to the >>> new cstruct. >>> >>> Does that interface seem ok? >>> >>> >>> At Sun, 5 Jun 2016 22:04:23 +0200, Berthold Bäuml wrote: Would it be possible to add for the serializable cstruct (define-serializable-cstruct) versioning like in define-serializable-struct/versions? Berthold -- --- Berthold Bäuml -- Head of Autonomous Learning Robots Lab DLR, Robotics and Mechatronics Center (RMC) Münchner Str. 20, D-82234 Wessling Phone +49 8153 282489 http://www.robotic.de/Berthold.Baeuml -- 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. >> >> -- >> --- >> Berthold Bäuml -- Head of Autonomous Learning Robots Lab >> DLR, Robotics and Mechatronics Center (RMC) >> Münchner Str. 20, D-82234 Wessling >> Phon
Re: [racket-users] RacketCon hotel discount?
Yes, I'll ping the hotel again... At Tue, 7 Jun 2016 14:21:43 -0700 (PDT), Brian Adkins wrote: > I noticed that the 2015 RacketCon had a "RAC" group code for the hotel. I > already booked my hotel, but it's a changeable/cancelable reservation, so is > there going to be a group discount for the hotel for this year's conference > also? If so, what is it, and when is it active? > > Brian > > -- > 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.
[racket-users] RacketCon hotel discount?
I noticed that the 2015 RacketCon had a "RAC" group code for the hotel. I already booked my hotel, but it's a changeable/cancelable reservation, so is there going to be a group discount for the hotel for this year's conference also? If so, what is it, and when is it active? Brian -- 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: Anyone attending RacketCon but *not* Strange Loop ?
On Tuesday, June 7, 2016 at 4:07:36 PM UTC-4, Brian Adkins wrote: > Just out of curiosity, is anyone attending RacketCon, but not attending > Strange Loop? > > I'm probably in the minority, but there don't seem to be enough compelling > sessions this year for me (although I'd love to hear Matthew's and Andy's > talk), so I'm considering flying in for RacketCon only. Seems a bit odd, but > saving $625 pays for most of the plane ticket, so that's a nice bonus :) > > Brian Adkins BTW - the Union Station hotel seems to be filling up, so it might be good to book a room before tomorrow when Strange Loop registration opens. -- 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] Anyone attending RacketCon but *not* Strange Loop ?
Just out of curiosity, is anyone attending RacketCon, but not attending Strange Loop? I'm probably in the minority, but there don't seem to be enough compelling sessions this year for me (although I'd love to hear Matthew's and Andy's talk), so I'm considering flying in for RacketCon only. Seems a bit odd, but saving $625 pays for most of the plane ticket, so that's a nice bonus :) Brian Adkins -- 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] Detecting mouse events on top of picts?
> Why don’t you check the location of the mouse movement? The coordinates are > close enough. I do check the location of the mouse movement to find a canvas location. What I was looking for a smarter way to do was to check whether or not that particular pixel was drawn by a particular pict that has previously been displayed in the canvas. My best approach thus far is to draw the pict into a bitmap, off-screen, and see if it the corresponding pixel has been modified. I was hoping that someone knew a smarter way, perhaps in a part of the GUI API that I had not found, but it doesn't seem to be the case. In any case, my current solution is working well enough for now. /David -- 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] (sixth RacketCon) Opportunity Grants
We are pleased to announce that (sixth RacketCon) will provide opportunity grants. These grants target Strange Loop opportunity grant [1] recipients who wish to attend RacketCon. The grants provide free RacketCon admission, as well as an additional hotel night, the night after RacketCon. If you are a recipient of a Strange Loop opportunity grant, and would be interested in attending RacketCon, please get in touch by June 21st at: stamo...@racket-lang.org We have a limited number of grants, which will be allocated on a first-come first-served basis. Thanks to Brian Mastenbrook for making these grants possible. See you in St. Louis! Vincent [1] https://thestrangeloop.com/opportunity.html -- 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 v6.5
On Thursday, 28 April 2016 15:57:50 UTC-4, Ryan Culpepper wrote: > Racket version 6.5 is now available from > > http://racket-lang.org/ [...] > Feedback Welcome The source built and runs on Solaris 10/sparc. (The previous version would not.) Thank you. N -- 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] Transforming data for plot / discreet-histogram
For now, you can use sequence-map to turn the hashtable into a sequence of vectors. #lang racket (require math) (require plot) (discrete-histogram (sequence-map vector (in-hash (samples->hash '(1 2 3 4 4) But it would be nicer if discrete-histogram took a hash as input. On Tue, Jun 7, 2016 at 10:44 AM, Sean Kemplay wrote: > Hello, > > Something like the following would be ideal to build a histogram from a > sequence of values read in via CSV > > #lang racket > (require math) > (require plot) > > (discrete-histogram (samples->hash '(1 2 3 4 4))) > > However discreet histogram takes a list of vectors. Is there a way to > achieve something like the above without managing a list of vectors for > 500,000+ rows of data? > > Reading the docs, I thought discrete-histogram would also take a list of > lists and that I could do something like (discrete-histogram (hash->list > (samples->hash '(1 2 3 4 4 but it looks like hash->list returns a list > of dotted pairs. > > Sorry, I dip in and out of Racket so I may be missing something obvious. > Maybe run through hash-map? > > Kind regards, > Sean > > -- > 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] define-serializable-cstruct with versions?
Sorry --- reading through your message one more time, I think I understand what you're saying. My example involved pointers to structures, and you're noting that *inlined* structures create a problem. One possibility is to treat a change to `_pond` as a change to `_forest`, too, and introduce a new version of `_forest`. Or, as you say, we could change the serialization protocol. Maybe it depends on how common you expect this case to be. At Tue, 7 Jun 2016 17:14:54 +0200, Berthold Bäuml wrote: > Sorry, I did not think this through completely. Serialization of cstructs, as > it is currently implemented, loses all “sub-structure” for non-pointer > content, correct? > > But wouldn’t because of this lost sub-structure your alternative > compatibility > protocol also fail when it comes to hierarchically embedded structs where > deep > down in the hierarchy a new version of a struct should be used? > > > (define-serializable-cstruct _pond ([depth _float])) > (define-serializable-cstruct _forrest ([a_pond _pond])) > > and then a new version: > (define-serializable-cstruct _old-pond ([depth _float])) > (define-serializable-cstruct _pond ([num-fish _int] >[depth _float]) > > (define-serializable-cstruct _forrest ([a_pond _pond])) > > So, the version of _forrest does not change and, hence, there is no way to > deserialize the correct, new version of the _pond. > > I think this could only be resolved by changing the serialization so that it > keeps all relevant information also for non-pointer content. > > Berthold > > On 06 Jun 2016, at 19:22, Matthew Flatt wrote: > > > > Yes, but I think a different protocol will be needed than for > > `serializable-struct`. > > > > With > > > > (serializable-struct pond (depth)) > > > > it's clear that the deserializer receives a single value for the single > > field (or, more generally, N values for N fields). So, it's clear how > > to make a compatibility deserialization function: > > > > (serializable-struct/versions pond 1 (num-fish depth) > > ([0 (lambda (d) (pond 0 d)) > > (lambda () )])) > > > > With > > > > (define-serializable-cstruct _pond ([depth _float])) > > > > the deserializer internally deals with a byte-string representation of > > non-pointer content plus a structured representation of pointer > > content. We probably don't want to expose those details, and you don't > > want to deal with them. > > > > An alternative it to make the compatibility protocol work in terms of a > > separate cstruct declaration: > > > > (define-serializable-cstruct _old-pond ([depth _float])) > > > > (define-serializable-cstruct _pond ([num-fish _int] > > [depth _float]) > > #:version 1 > > #:other-versions ([0 deserialize-chain:cstruct:old-pond > >(lambda (op) > > (make-pond 0 (old-pond-depth op))) > >(lambda () )])) > > > > That is, compatibility deserialization is based on a reference to > > deserialization information for a cstruct that has the same shape as > > the old version, plus converters from instances of the old shape to the > > new cstruct. > > > > Does that interface seem ok? > > > > > > At Sun, 5 Jun 2016 22:04:23 +0200, Berthold Bäuml wrote: > >> Would it be possible to add for the serializable cstruct > >> (define-serializable-cstruct) versioning like in > >> define-serializable-struct/versions? > >> > >> Berthold > >> > >> -- > >> --- > >> Berthold Bäuml -- Head of Autonomous Learning Robots Lab > >> DLR, Robotics and Mechatronics Center (RMC) > >> Münchner Str. 20, D-82234 Wessling > >> Phone +49 8153 282489 > >> http://www.robotic.de/Berthold.Baeuml > >> > >> -- > >> 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. > > -- > --- > Berthold Bäuml -- Head of Autonomous Learning Robots Lab > DLR, Robotics and Mechatronics Center (RMC) > Münchner Str. 20, D-82234 Wessling > Phone +49 8153 282489 > http://www.robotic.de/Berthold.Baeuml > > -- > 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 h
Re: [racket-users] define-serializable-cstruct with versions?
I think all this works ok. I've enclosed an example interaction from the docs, which I've just extended to evolve `fish` in addition to `aq`. So, it's all implemented, and I can push if it seems like an ok interface... At Tue, 7 Jun 2016 17:14:54 +0200, Berthold Bäuml wrote: > Sorry, I did not think this through completely. Serialization of cstructs, as > it is currently implemented, loses all “sub-structure” for non-pointer > content, correct? > > But wouldn’t because of this lost sub-structure your alternative > compatibility > protocol also fail when it comes to hierarchically embedded structs where > deep > down in the hierarchy a new version of a struct should be used? > > > (define-serializable-cstruct _pond ([depth _float])) > (define-serializable-cstruct _forrest ([a_pond _pond])) > > and then a new version: > (define-serializable-cstruct _old-pond ([depth _float])) > (define-serializable-cstruct _pond ([num-fish _int] >[depth _float]) > > (define-serializable-cstruct _forrest ([a_pond _pond])) > > So, the version of _forrest does not change and, hence, there is no way to > deserialize the correct, new version of the _pond. > > I think this could only be resolved by changing the serialization so that it > keeps all relevant information also for non-pointer content. > > Berthold > > On 06 Jun 2016, at 19:22, Matthew Flatt wrote: > > > > Yes, but I think a different protocol will be needed than for > > `serializable-struct`. > > > > With > > > > (serializable-struct pond (depth)) > > > > it's clear that the deserializer receives a single value for the single > > field (or, more generally, N values for N fields). So, it's clear how > > to make a compatibility deserialization function: > > > > (serializable-struct/versions pond 1 (num-fish depth) > > ([0 (lambda (d) (pond 0 d)) > > (lambda () )])) > > > > With > > > > (define-serializable-cstruct _pond ([depth _float])) > > > > the deserializer internally deals with a byte-string representation of > > non-pointer content plus a structured representation of pointer > > content. We probably don't want to expose those details, and you don't > > want to deal with them. > > > > An alternative it to make the compatibility protocol work in terms of a > > separate cstruct declaration: > > > > (define-serializable-cstruct _old-pond ([depth _float])) > > > > (define-serializable-cstruct _pond ([num-fish _int] > > [depth _float]) > > #:version 1 > > #:other-versions ([0 deserialize-chain:cstruct:old-pond > >(lambda (op) > > (make-pond 0 (old-pond-depth op))) > >(lambda () )])) > > > > That is, compatibility deserialization is based on a reference to > > deserialization information for a cstruct that has the same shape as > > the old version, plus converters from instances of the old shape to the > > new cstruct. > > > > Does that interface seem ok? > > > > > > At Sun, 5 Jun 2016 22:04:23 +0200, Berthold Bäuml wrote: > >> Would it be possible to add for the serializable cstruct > >> (define-serializable-cstruct) versioning like in > >> define-serializable-struct/versions? > >> > >> Berthold > >> > >> -- > >> --- > >> Berthold Bäuml -- Head of Autonomous Learning Robots Lab > >> DLR, Robotics and Mechatronics Center (RMC) > >> Münchner Str. 20, D-82234 Wessling > >> Phone +49 8153 282489 > >> http://www.robotic.de/Berthold.Baeuml > >> > >> -- > >> 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. > > -- > --- > Berthold Bäuml -- Head of Autonomous Learning Robots Lab > DLR, Robotics and Mechatronics Center (RMC) > Münchner Str. 20, D-82234 Wessling > Phone +49 8153 282489 > http://www.robotic.de/Berthold.Baeuml > > -- > 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. > (define-serializable-cstruct fish ([color _int])) > (define f0/s (serialize (make-fish 1))) > (fish-color (deserialize f0/s)) 1 > (define-serializable-cstruct aq ([a fish-pointer]
Re: [racket-users] define-serializable-cstruct with versions?
Sorry, I did not think this through completely. Serialization of cstructs, as it is currently implemented, loses all “sub-structure” for non-pointer content, correct? But wouldn’t because of this lost sub-structure your alternative compatibility protocol also fail when it comes to hierarchically embedded structs where deep down in the hierarchy a new version of a struct should be used? (define-serializable-cstruct _pond ([depth _float])) (define-serializable-cstruct _forrest ([a_pond _pond])) and then a new version: (define-serializable-cstruct _old-pond ([depth _float])) (define-serializable-cstruct _pond ([num-fish _int] [depth _float]) (define-serializable-cstruct _forrest ([a_pond _pond])) So, the version of _forrest does not change and, hence, there is no way to deserialize the correct, new version of the _pond. I think this could only be resolved by changing the serialization so that it keeps all relevant information also for non-pointer content. Berthold > On 06 Jun 2016, at 19:22, Matthew Flatt wrote: > > Yes, but I think a different protocol will be needed than for > `serializable-struct`. > > With > > (serializable-struct pond (depth)) > > it's clear that the deserializer receives a single value for the single > field (or, more generally, N values for N fields). So, it's clear how > to make a compatibility deserialization function: > > (serializable-struct/versions pond 1 (num-fish depth) > ([0 (lambda (d) (pond 0 d)) > (lambda () )])) > > With > > (define-serializable-cstruct _pond ([depth _float])) > > the deserializer internally deals with a byte-string representation of > non-pointer content plus a structured representation of pointer > content. We probably don't want to expose those details, and you don't > want to deal with them. > > An alternative it to make the compatibility protocol work in terms of a > separate cstruct declaration: > > (define-serializable-cstruct _old-pond ([depth _float])) > > (define-serializable-cstruct _pond ([num-fish _int] > [depth _float]) > #:version 1 > #:other-versions ([0 deserialize-chain:cstruct:old-pond >(lambda (op) > (make-pond 0 (old-pond-depth op))) >(lambda () )])) > > That is, compatibility deserialization is based on a reference to > deserialization information for a cstruct that has the same shape as > the old version, plus converters from instances of the old shape to the > new cstruct. > > Does that interface seem ok? > > > At Sun, 5 Jun 2016 22:04:23 +0200, Berthold Bäuml wrote: >> Would it be possible to add for the serializable cstruct >> (define-serializable-cstruct) versioning like in >> define-serializable-struct/versions? >> >> Berthold >> >> -- >> --- >> Berthold Bäuml -- Head of Autonomous Learning Robots Lab >> DLR, Robotics and Mechatronics Center (RMC) >> Münchner Str. 20, D-82234 Wessling >> Phone +49 8153 282489 >> http://www.robotic.de/Berthold.Baeuml >> >> -- >> 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. -- --- Berthold Bäuml -- Head of Autonomous Learning Robots Lab DLR, Robotics and Mechatronics Center (RMC) Münchner Str. 20, D-82234 Wessling Phone +49 8153 282489 http://www.robotic.de/Berthold.Baeuml -- 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] Constructor-style printing for sets?
> On Jun 6, 2016, at 10:24 PM, Alex Knauth wrote: > > If I run this program: > > #lang racket > (set 1 2 3) > > It prints out the value: > > (set 1 2 3) > > That's wonderful! It uses nice constructor-style printing, just like I > wanted. That was without changing the printing settings from the default > print mode. > > However, if I change DrRacket's printing settings to use constructor-style > printing instead, I get this: > > (immutable-custom-set ...) > > The constructor-style printing mode in DrRacket uses `print-convert` from > `mzlib/pconvert` to do this, and the `racket/set` library already uses > `gen:custom-write` for constructor-style printing. > > Should `racket/set` sets also use a property similar to > `prop:print-converter` that `print-convert` can recognize and use? Or should > sets be another case in the implementation of `print-convert`? Would something like a `prop:constructor-style-printer` property make sense here? It would imply `prop:custom-write` with a `make-constructor-style-printer` value, so it would also cooperate with pretty printing. And anything like `print-convert` that wants to deal with s-expressions could recognize this property and use it to do the right thing. > (struct point (x y) #:property prop:constructor-style-printer (list (lambda (p) 'point) (lambda (p) (list (point-x p) (point-y p) > (print (point 1 2)) (point 1 2) > (print-convert (point 1 2)) (list 'point 1 2) > (parameterize ([pretty-print-columns 10]) (pretty-print (point 300 400))) (point 300 400) Does this seem like something that should be added to `racket/struct` next to `make-constructor-style-printer`? > Alex Knauth -- 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] Transforming data for plot / discreet-histogram
Hello, Something like the following would be ideal to build a histogram from a sequence of values read in via CSV #lang racket (require math) (require plot) (discrete-histogram (samples->hash '(1 2 3 4 4))) However discreet histogram takes a list of vectors. Is there a way to achieve something like the above without managing a list of vectors for 500,000+ rows of data? Reading the docs, I thought discrete-histogram would also take a list of lists and that I could do something like (discrete-histogram (hash->list (samples->hash '(1 2 3 4 4 but it looks like hash->list returns a list of dotted pairs. Sorry, I dip in and out of Racket so I may be missing something obvious. Maybe run through hash-map? Kind regards, Sean -- 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] smtp-send-message to gmail
On 6/7/2016 5:18 AM, Лера Гранкина wrote:
I'm trying to send message using the code below, but I always get error "No reply
from computer".
(require net/smtp net/dns openssl/mzssl net/head)
(smtp-send-message
(dns-get-address "192.168.5.254" "smtp.gmail.com")
"m...@gmail.com"
'("m...@gmail.com")
(standard-message-header
"Sender "
'("Recipient ")
'()
'()
"Subject")
'("Hello World")
#:port-no 465
#:auth-user "m...@gmail.com"
#:auth-passwd "mypassword"
#:tcp-connect tcp-connect)
Gmail requires a secure connection: use #:tcp-connect ssl-connect
George
--
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] Proper handling for a custom current-read-interaction?
The intention here is that you should have a notion of an expression that is itself consistent and you should read until you get a whole one of those and then just return that. The different behavior you see in DrRacket and at the terminal window prompt will, yes, cause different behavior, but it isn't supposed to be something that you would explicitly check for and respond to. In the case of the DrRacket window, DrRacket makes the assumption that your expressions will be terminated by an EOF and puts those into the port between each submission that the user makes in order to support things like typing alt-return (something that doesn't happen at the terminal window). Robby On Mon, Jun 6, 2016 at 11:09 PM, Alexis King wrote: > I am trying to write a custom current-read-interaction for a language > with non-s-expression syntax, and I’m not sure I completely understand > the protocol for how to detect the end of input across both the command > line and DrRacket. I first wrote an implementation for DrRacket, which > appears to continually call current-read-interaction until it returns > #, at which point it presents the user a new prompt. Therefore, I > simply decided to check char-available? on the provided port and return > # whenever the port returned #f. This seems to work fine in > DrRacket. > > On the other hand, I found it does not work at all on the command line. > Returning # on the command line just seems to kill the entire REPL. > Furthermore, unlike DrRacket, the CLI does not seem to produce an EOF at > the end of each expression, just a newline, re-using the same port each > time. Checking for a newline in DrRacket would not work at all, though, > because DrRacket permits entering multiline expressions in its REPL. > > This would lead me to believe that there are two completely different > protocols for how the two different REPLs work: > > 1. In DrRacket, read all the contents in the port provided to > current-read-interaction. Check the port against char-available? > each call, and return # when it returns #f. > > 2. At the command line, read all contents up until a newline. Check > the port against peek-char each call, and return # when it > returns # to support exiting the REPL by sending ^D. > > These seem totally different, frustratingly so, since it seems like it > would not be too hard for the CLI to use the same behavior as DrRacket. > My guess is that I’m overcomplicating things at least a little, but I > wasn’t able to locate anything about what exactly is expected of the > function provided to current-read-interaction. Is there a way to > implement it that can gracefully handle both scenarios? If not, what is > the proper way to check if code is running in the CLI REPL or the > DrRacket REPL and adjust behavior accordingly? > > Alexis > > -- > 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.
[racket-users] smtp-send-message to gmail
I'm trying to send message using the code below, but I always get error "No
reply from computer".
(require net/smtp net/dns openssl/mzssl net/head)
(smtp-send-message
(dns-get-address "192.168.5.254" "smtp.gmail.com")
"m...@gmail.com"
'("m...@gmail.com")
(standard-message-header
"Sender "
'("Recipient ")
'()
'()
"Subject")
'("Hello World")
#:port-no 465
#:auth-user "m...@gmail.com"
#:auth-passwd "mypassword"
#:tcp-connect tcp-connect)
--
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.
