[racket-users] encountered old PLT Scheme GUI that still works great

[JCG]

Just an interesting thing.  I restarted work back at a place that I left 
several years back where we still use a custom IDE written in PLT Scheme 
4.25, just before it became Racket.  It's about 25K lines of GUI.  Out of 
curiosity, I recompiled everything today on 7.2.0.6 Chez racket.  I ran 
into two small problems to fix and then it ran great, but faster.   So, 
despite considerable and ongoing improvements, a considerable old piece of 
code continues doing just fine after a decade of Racket evolution.   Thanks.

-- 
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: Why is there a space in the path to the Racket application on MacOSX?

[JCG]

Count me in as a person who renames racket installations without spaces.

It is more prudent to design file names without special characters, 
escapes, or quotes.  Otherwise, any shell script that might otherwise work 
on most unix file names may fail.  It's just not worth the hassle guessing 
if all of a system's scripts will be compatible.  As an example, AWK 
scripts used in a pipe are quite susceptible to surprise when one field 
appears as two.  Ditto for 'sort +k ...'.   

A further reason to eschew spaces in file name is documentation.   Having a 
space in a file name within prose is quite likely going to suffer a 
confusing line split. 

Thanks,
JG

>
>

-- 
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] typed/racket #:break #:guard

[JCG]

Sam, thanks very much for the response. 

I only looked at the documentation for for/first after Dr Racket said "add 
more type annotations" a few times.  From a user viewpoint, I feel that a 
usually non-functioning form would benefit from an example of working usage 
so that I can bend my form to fit any limitations. In most places, 
transitioning my code to Typed Racket worked so easily that I came to 
expect my forms to work.

I'm glad that #:break is not a usage mistake, because I'm definitely 
replacing for/first with for/fold with a #:break. 

I'm not sure what to say on #:guard, except that it makes moving some 
non-TR code easier.

By the way, removing contracts and adding types on about 2500 lines 
resulted in about 10 LOC difference.  The speed of runtime code slightly 
favors TR.

-JG


On Saturday, January 27, 2018 at 3:33:44 PM UTC-5, Sam Tobin-Hochstadt 
wrote:
>
> Hi JG, 
>
> You're correct that the `for/first` and `for/last` forms don't work 
> usually in TR, but that's what the documentation says: "Like the 
> above, except they are not yet supported by the typechecker.". Is 
> there a different way that could be phrased to make this clearer? 
>
> The omission of `#:break` in the documentation is just an oversight. A 
> PR fixing that would be welcome, or I'll try to do it soon. 
>
> `#:guard` is not intended to be used, because the type checker doesn't 
> understand what it does. However, some existing TR code relies on the 
> current treatment, so it isn't an error. 
>
> Sam 
>
> On Fri, Jan 26, 2018 at 6:06 AM, JCG <griff...@gmail.com > 
> wrote: 
> > 
> > In doing some typed/racket, I have noticed some mismatch between 
> observed 
> > behavior and the documentation at 
> > 
> > https://docs.racket-lang.org/ts-reference/special-forms.html 
> > 
> > 1) Documentation suggests that for/first and for/last should work, yet 
> they 
> > seem to not type check.  I've noticed sparse comments to that effect 
> since 
> > 2014. 
> > 
> > 2) In working around for/first with for/fold, I discovered that #:break 
> > appears to function although the for loop documentation for typed racket 
> > (Section 2.3 in typed/racket reference) suggests that only the #:when 
> guard 
> > is a keyword in the for/ family syntax. 
> > 
> > 3) In the struct documentation for typed racket, the many for syntax 
> > keywords shown do not include #:guard, yet it seems to work. 
> > 
> > Are #:break and #:guard correct to use in typed/racket or are they 
> missing 
> > from the documentation intentionally? 
> > 
> > Thanks, 
> > JG 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > -- 
> > 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...@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] typed/racket #:break #:guard

[JCG]

In doing some typed/racket, I have noticed some mismatch between observed 
behavior and the documentation at

https://docs.racket-lang.org/ts-reference/special-forms.html

1) Documentation suggests that for/first and for/last should work, yet they 
seem to not type check.  I've noticed sparse comments to that effect since 
2014.

2) In working around for/first with for/fold, I discovered that #:break 
appears to function although the for loop documentation for typed racket 
(Section 2.3 in typed/racket reference) suggests that only the #:when guard 
is a keyword in the for/ family syntax. 

3) In the struct documentation for typed racket, the many for syntax 
keywords shown do not include #:guard, yet it seems to work.

Are #:break and #:guard correct to use in typed/racket or are they missing 
from the documentation intentionally?

Thanks,
JG








-- 
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: Alternatives to DrRacket

[JCG]

Sorry for the delay. 

1) Coloring of a #; commented-out S-expression, as in Emacs.

2) Code folding that is saved and yet compatible with external editors.  
The way I would go about dealing with the WXME format would be be to save 
two files, with the WXME format hidden somewhere (Sqlite or a file) based 
on the hash of the content of the normal text.  If the hash matches, then 
utilize the extra goodies the WXME affords (e.g. code folding); otherwise 
just show the normal text version and nobody will be the wiser.  

3) Having the ability for the Run button to execute a different process 
would allow crash-prone C/C++/Go/Rust extensions not annihilate the GUI.

4) The first attempt to get assistance from meta-/ takes quite a while yet 
excludes operators defined in the current file.  Given that it's not 
including local definitions and/or tokens, and that the next time I start 
DrRacket, the same list will slowly appear, it ought to be cached.

5) Easy way to avoid byte-code incompatibility, e.g. I download 6.12.0.3 
and run into a repetitive dialog about 6.10 byte-code incompatibility 
without any option for correction.

6) In the preferences dialog (on a Mac at least), the "Revert All 
Preferences to Defaults" is unclear about whether the defaults are for the 
displayed tab or for all preferences.  At least twice in the past, I've 
incorrectly assumed that the defaults were for the topic displayed and not 
all preferences.  I fiddled with the background expansion and finally 
decided "Oh, I'll just put it back to whatever is suggested - bam, all my 
other settings were gone."

7) Finally, the tools tab has doubtful defaults for preloading tools, e.g. 
Algol 60.   Then there is the question about what "Skip the tool" means.  
Does that mean that I cannot access these in a running Dr Racket? 

Thanks for asking suggestions.

-John


On Sunday, November 26, 2017 at 10:42:29 AM UTC-5, spdegabrielle wrote:
>
> Hi,
>
> I’ve noticed some list members use other editors or IDE’s. 
>
> I know two big reasons for using a complex tool is it’s stickiness 
> factors; normally a combination of familiarity (hence speed) with a lot of 
> powerful features and non-transportable customisation.
>
> Putting stickiness factors aside, what features in other editors/IDE’s 
> would you like to see in DrRacket?
>
> Kind regards,
>
> Stephen
>
>
> -- 
> Kind regards,
> Stephen
> --
> Ealing (London), UK
>

-- 
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] Narrow radix of string->number.

[JCG]

On Thursday, December 29, 2016 at 5:54:08 PM UTC-5, gustavo wrote:
> I'm not too worried about a x4 slowdown in number->string because I
> don't expect it to be in a tight loop, but it would be nice that it
> were faster.

In fact, I find number->string already a tad slow, because I do use it in a 
loop.  

Anyway, I don't want to complain about speed down the road without mentioning 
now that I would consider any 4x slowdown unpleasant.

A base-10 user,
JG

-- 
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: New website design feedback

[JCG]

On Friday, December 23, 2016 at 9:55:13 AM UTC-5, Greg Trzeciak wrote:
> Firstly - congratulations to Matthew Butterick on beautiful design!
> 

Ditto - the new page is very appealing.

-- 
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: REPL output editor speed

[JCG]

On Monday, December 19, 2016 at 10:35:33 AM UTC-5, JCG wrote:
> I’m in an situation where Dr. Racket suffices almost perfectly to replace a 
> Python-based IPython notebook session.  The REPL output is graphics and text, 
> perfect for Dr. Racket.  
> 
> A problem is that for all but the smallest output, the REPL text output is 
> simply too lethargic, even compared to the already slow IPython notebook.  
> Some of the text output from commands is about 10K lines and Dr. Racket 
> struggles to trickle the lines over 10+ seconds.  I have tried OSX and Ubuntu 
> but not Windows. 
> 
> I tested writing to an editor with open-output-text-editor.  It acts quite 
> similarly to the Racket REPL performance.  It’s nice, but too slow.
> 
> I then tried (send my-editor insert the-text) and it’s quite fast enough.
> 
> My goal is thus to have the whole Dr Racket experience, but with the ability 
> to quickly write textual data into the REPL.  Some ameliorating ideas follow.
> 
> 1) I assume that if I were to get access to the REPL editor, I could insert 
> into it directly in the case where I have a large quantity of conceptually 
> atomic output text.   I don’t see how to attain a reference to the current 
> output editor.
> 
> 2) I could pop up my own frame for this output, but the inline output of the 
> standard REPL is a more consistent interface.
> 
> 3) Perhaps there is a place to alter the apparent granularity of insertion 
> into the REPL from (current-output-port)?   It appears to be based on either 
> characters or lines, but larger chunks would be great.
> 
> 4) Don’t laugh, but I also experimented with writing subsections of the text 
> into sequential images and outputting those.  It’s super quick and looks 
> great, but then the text isn’t really there (e.g. for copy to clipboard).
> 
> I’m open to suggestions, particularly one that uses something already built 
> that I neglected to read about.
> 
> Many thanks in advance,
> John Griffin

One thing that I have found is that an Ubuntu 16.04 on a slighter slower iMac 
scrolls noticeably (feels 2x) faster than OSX on a faster iMac (Yes, I have 
multiple old iMacs).



-- 
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] REPL output editor speed

[JCG]

Thanks for the code reference.  That will definitely take a while for me to 
grok.  I will punt with a separate editor window for now and later get 
acquainted with the framework text.rkt code.

Thanks again,
John

-- 
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] REPL output editor speed

[JCG]

I’m in an situation where Dr. Racket suffices almost perfectly to replace a 
Python-based IPython notebook session.  The REPL output is graphics and text, 
perfect for Dr. Racket.  

A problem is that for all but the smallest output, the REPL text output is 
simply too lethargic, even compared to the already slow IPython notebook.  Some 
of the text output from commands is about 10K lines and Dr. Racket struggles to 
trickle the lines over 10+ seconds.  I have tried OSX and Ubuntu but not 
Windows. 

I tested writing to an editor with open-output-text-editor.  It acts quite 
similarly to the Racket REPL performance.  It’s nice, but too slow.

I then tried (send my-editor insert the-text) and it’s quite fast enough.

My goal is thus to have the whole Dr Racket experience, but with the ability to 
quickly write textual data into the REPL.  Some ameliorating ideas follow.

1) I assume that if I were to get access to the REPL editor, I could insert 
into it directly in the case where I have a large quantity of conceptually 
atomic output text.   I don’t see how to attain a reference to the current 
output editor.

2) I could pop up my own frame for this output, but the inline output of the 
standard REPL is a more consistent interface.

3) Perhaps there is a place to alter the apparent granularity of insertion into 
the REPL from (current-output-port)?   It appears to be based on either 
characters or lines, but larger chunks would be great.

4) Don’t laugh, but I also experimented with writing subsections of the text 
into sequential images and outputting those.  It’s super quick and looks great, 
but then the text isn’t really there (e.g. for copy to clipboard).

I’m open to suggestions, particularly one that uses something already built 
that I neglected to read about.

Many thanks in advance,
John Griffin



-- 
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] small cosmetic comment

[JCG]

On the mailing lists section of the Racket site, there are users, announcements 
and dev groups.  Underneath each are three IMG tags referencing bad urls, e.g.

http://gmane.org/plot-rate.php?group=gmane.comp.lang.racket.user

I just thought to mention it after seeing dead-link pictures for quite some 
time.

Thanks again for Racket,
John Griffin

-- 
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] OSX/Racket/Golang shared libraries warning

[JCG]

First, this is absolutely not referencing a racket bug.   I feel obligated to 
warn anybody that believes the assertion that GO now generates shared libraries 
consumable by no-GO code.

It's true.  Go generates a shared library, and you can call to it from Racket, 
but I can attest to two issues:

1) Expect crashes on OSX.   Go attempts to make its runtime system compatible 
with code anticipating a extern C interface.   There's lots of chatter with 
people running into "runtime/cgo: could not obtain pthread_keys", but none that 
mention Racket that I see.  However, it does crash inside of DrRacket on OSX.  
Googling delivers examples of Python and Node having similar crashes.

2) Dreadful speed.  Even when functioning, i.e. not on OSX, the speed is 
incredibly slow.  I believe that extern "C" style code runs in a separate GO 
routine and performance-hampering context switching is involved.   I'm talking 
about 1/35 of the speed of calling C/C++ from Racket.

So, this is just a warning to lower expectations if you are thinking about 
calling Go code from an FFI such as Racket's, or if you expect it to work on a 
Mac.  I hope the warning saves somebody a few hours of pain.

As always, thanks for Racket.



-- 
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] OSX 10.12

[JCG]

"You have OS X 10.11.6. The application requires OS X 10.12 or later."

That's the error my 64bit Mac sees running 6.7.0.1 Dr. Racket from the normal 
.app icon.  However, running the executables directly, e.g. 
the-directory/bin/drracket works.

I don't know if the app launch requirement for 10.12 is intentional or not - 
I'm guessing not.

On a happy side note - it's faster than my 6.6 install, both in measurement and 
in feel.

-- 
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: Good parser library in Racket

[JCG]

On Saturday, October 1, 2016 at 2:00:23 PM UTC-4, ckkashyap wrote:
> Hi Racket users,
> It appears that parser-tools/yacc is the parser tool that's bundled with 
> racket by default. I'd like to parse java like language. I was wondering if 
> there is already such an implementation that I could use or perhaps a 
> reference implementation I could use. The example in the sources - calc.rkt 
> is not quite enough :)
> Ofcourse, I am not particular about using yacc - but I am inclined towards it 
> because it is bundled by default.
> Thanks,
> Kashyap

https://docs.racket-lang.org/honu/index.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] modern C++ likes Racket

[JCG]

Just a note in case it's not obvious.  Modern C++14, using std::make_shared, 
can be used with Racket.  Mainly due to the make-phantom-bytes call,  Racket's 
GC collects memory at appropriate intervals for my work.  

If anyone needs to access std::shared_ptr stuff in Racket, I find that 
wrapping the shared_ptr in a (return new boost::any(the-thing)) and having a 
general-purpose (register-finalizer) call handles the C++ destruction and 
typing of the boost::any content just fine.

Thanks for a fast and well-thought FFI.




-- 
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] Thanks for 6.4 changes

[JCG]

Just a thanks to everyone that was involved in 6.4, but right off the bat, I 
see the following things that affect me positively

1) The Cheat Sheet at the top of the doc.  Thanks to that, I've just discovered 
cfg-parser.

2) I had asked for better release notes and here they are.

3) Noticeably faster scrolling in the interactions window.  

Nice work, again.

JG

-- 
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: Code critique request: data/fetch, proc for walking hashes/lists

[JCG]

On Sunday, January 10, 2016 at 4:44:57 PM UTC-5, David K. Storrs wrote:
> I feel like I'm starting to be somewhat functional with Racket, but I'd like 
> to get more idiomatic.  I'd appreciate it if people would critique the 
> following code:
> 
> 
> (define (data/fetch s key-list)
>   (if (or (empty? s)
>   (nor (list? s)
>    (hash? s)))

I'm not the one to answer about what is idiomatic Racket, but I'd probably be 
using (cond).

  (cond
[(hash? s)..]
[(pair? s)...]
[ else ...])

Also, you probably want a 4th parameter to hash-ref for failed lookup.

More than anything, thanks for using (nor).  I did not know of it beforehand.

JG




-- 
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] typed compilation option again

[JCG]

I alluded to a compilation option to enable/disable types, much in the way of

typed/racket

 and

typed/racket/no-check.


In my foray into using Typed Racket, two performance issues persist, 
compilation speed and runtime speed of my hybrid code.   The reasons why are 
clear and the fact that it works at all is great.

Not having that option to 'raco exe ...', I changed all my #lang lines in 40 
files to:

#lang s-exp "mytyped.rkt"

That "mytyped.rkt" file contains:

-
#lang racket

;;
; This permits flip-flopping between
; typed and typed/no-check
;
; Use one and comment the other
;;

;;
; Type checking active
#;(require typed/racket)
#;(provide (all-from-out typed/racket))

;
; Type checking inactive
(require typed/racket/no-check)
(provide (all-from-out typed/racket/no-check))
(define-syntax-rule (require/typed module-name ignored ...)
  (require module-name))
(provide require/typed)
-

I comment out the undesired section, enabling/disabling type checking.  Using 
my test suite, here's how three programs compare in relation to compilation and 
execution time.

Previous untyped version:
 Compilation time: 13 seconds
 Execution time: 18 minutes

Hybrid version with type checking on:
 Compilation time: 178 seconds
 Execution time: 33 minutes

Hybrid version with type checking off:
 Compilation time: 44 seconds
 Execution time: 22 minutes

The executable in both hybrid versions is 16 megs, about double the untyped 
compiled size.  Runtime memory use is similar across all three and proportional 
to the number of instantiated places.  The result of this test is about 122,000 
time series; they match output in all versions.

Note that mytyped.rkt includes a macro for an apparently missing require/typed 
form.  



One question that concerns me is whether the following statement is correct:

A typed program that does not have conditions based upon type predicates, e.g. 
port? or integer?, should act the same when stripped of its types.  

-

Anyway, this felt like too easy a way to get my hybrid performance back.  If 
the Typed version actually ends up faster, then I'm set too.  If anyone sees 
something faulty or improvable, I'm open to advice.

Thanks (again),
John Griffin






-- 
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] Typed/Untyped cost reduction and experience

[JCG]

> I will say this as the first Racketeer and Typed Racketeer: if you just want 
> to program in an explicitly-statically typed language (possibly with 
> inference), you might wish to broaden your scope of search. There are other 
> expressively typed languages that come with good libraries. Most of these 
> languages are much more mature than TR and probably more reliable and stable 
> (in this sense). 
> 
> I am not sending you away. I am a scientist-designer who wants 
> user-developers to be highly informed. 

I'm looking for a middle ground between Python and C++, the two basic language 
tools in use at the office.   I like typing fast with my fingers and typing 
loose with my data, until it passes 100 lines of Python, the point at which my 
opinion flips 180 degrees.  After 100 lines, my option is to go to C++ or put 
another tool in the mix.  Here are my constraints for a potential middle ground 
tool:

1) It must run on command-line non-X11 Linux, (and OSX as well if possible)
2) It must have a reasonable FFI to use our proprietary C++ libraries and allow 
foreign controlled data structures.  There are pointers to substantial C++ side 
heap allocations requiring execution of C++ destructors at disposal time.
3) The nature of our library calls is that a language permitting optional named 
arguments
 is almost a requirement to harness the capabilities of our library.
4) It must be considerably more productive than C++, otherwise it's C++
5) I've had enough uncaught flaws in Python that I'm now convinced that I need 
types.
6) It needs pattern matching, otherwise I'm back to C++, flex and bison or I 
have to figure out Stroustrup's Mach 7 which does not yet seem settled.
7) A reasonable size, polite, and intelligent group driving the technology.

My preferences include:

1) reasonably fast executables
2) Lightweight threads
3) Reasonable ability to use multiple cores safely.
4) Reliable environment generating reliable JavaScript
5) Immutability of data
6) Weighted more towards functions than objects


So, two things come to mind, Racket and SBCL because I've used them before, and 
the ML family - Haskell, OCaml, and Scala.   Having tried Scala, I like the 
language but the associated environmental baggage appeared heavy and brittle 
from build dependencies. Both Haskell and OCaml seem quite plausible.  Having 
types potentially in Racket keeps it in the running.

Anyway, Racket floated first to the top because I reimplemented a network 
service that really needed pattern matching to combat the growing complexity of 
patterns.   I grabbed a familar (untyped) Racket and made a prototype.  
Unfortunately, the prototype worked so well that I'm using it now for real.  
Nevetheless, it has the smell of something that might be easier to maintain 
long-term with compiler-checked type annotations.  Typed Racket has improved or 
at least my utilization of it considerably since I looked at it about 4 years 
back.  Likewise, the places module which had previously been for me ungrokkable 
and lethargic was now easy and fast enough.

While those MLs are definitely still in mind, I'm going to get more comfortable 
with Typed Racket first.

-- 
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] typed/racket involved in matched (or)

[JCG]

I just did another workaround, this time better for me anyway.   This is all to 
accommodate deprecated end-user data identifiers while promoting 
better-conceived names.

I separated the (or pattern1, pattern2...) into a separate (normalize-request) 
function and removed the inline versions.  As a side benefit, I've now got a 
nice place to identity use of deprecated usage.

-- 
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] Typed/Untyped cost reduction and experience

[JCG]

On Tuesday, January 5, 2016 at 2:12:44 PM UTC-5, Matthias Felleisen wrote:
> Late but I want to record principles and experiences in this thread: 
> 

> I don't understand this bullet. Bullet 1 says your code is now completely 
> typed. Our experience is that completely typed versions are about as fast and 
> on many occasions (eg., numeric) faster than completely untyped versions. 
> 

Yes, it was hybrid and is still, although today I made quite a few conversions 
where the cost/benefit (all mental cost/benefit, not speed) was conducive.  
This project is 40 files, 17 of which are hybrid with untyped code in 
submodules.

I started this Typed Racket in mid-December, but I'm getting there.   My 
feeling is that I rather like making small modules with typed borders but 
sometimes untyped implementations.   I look forward to seeing future 
performance improvements in these hybrids.






-- 
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] Have not found my (place)

[JCG]

On Monday, January 4, 2016 at 1:02:30 PM UTC-5, Matthew Flatt wrote:
> I've pushed a repair for this bug.
> 
> Thanks for the report!

Thanks for the fix.   It works well.

-- 
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: Rust vs. C as a complement to Racket?

[JCG]

I'd like to add that I'm reasonably pleased with my C++ libraries running 
inside Racket.  Thanks to the recent fix with phantom bytes, the garbage 
collector does a steady job of calling my disposal routine.

Currently, the C++ library is mostly executed by Python, but Racket is 
gradually supplanting it.

Anyway, it works quite well from Racket.

-- 
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] Have not found my (place)

[JCG]

On Debian, the code below runs in compiled mode (raco exe test.rkt) in Racket 
6.2.1.  However, In Racket 6.3, dynamic-require chokes. 

dynamic-require: unknown module
  module name: #

In 6.3.0.10, it fails differently

place: contract violation
  expected: (or/c module-path? path?)
  given: '''name
  context...:
   /usr/racket-6.3.0.10/collects/racket/place.rkt:110:0: start-place

If running this code via "racket test.rkt", then it works in all versions. 

Thanks,
JG


#lang racket


(define (some-place-stuff)  

  (define places
  
(for/list ((i 4))   
  
  (place pch
  
 (define R (place-channel-get pch)) 
  
 (place-channel-put pch (+ R R) 
  

  (for ((i (in-range (length places)))  
  
(p (in-list places)))   
  
(place-channel-put p i))
  
  
  (for ((p (in-list places)))   
  
(printf "~a\n" (place-channel-get p 
  


(module+ main   

  (some-place-stuff))   


-- 
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] typed/racket involved in matched (or)

[JCG]

That's okay.  I wrote a really fancy workaround, whose API consists of (S).

(: S (-> (Option String) String))
(define (S s)
  (cast S String))

By the way, Typed Racket picked up the second statically discovered bug as I 
keep moving stuff out of untyped modules.  Not surprisingly, neither bug had 
been discovered in usage, but both instances were valid possible uses of the 
system.   So, having to punt with (S) is an excellent tradeoff.

Thanks for continued Racket evolution.

-- 
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] typed/racket involved in matched (or)

[JCG]

Within typed/racket, the type of NAME below is (U False String).  The type of 
COUNTRY and INDICATOR are simply String.  The values are always String.  All 
the (or) based patterns 

Any idea about how to have the (or pattern1 pattern2) identify as String?  I 
can cast it of course, but prefer not to.


(match a-list-of-strings

[(list "COUNTRY" COUNTRY INDICATOR)
 (trading-economics COUNTRY INDICATOR)]

...

 [(or (list "CBOE" NAME)
(list "XCBOE" NAME))
 #:when (member NAME cboe-record-names)
 (cboe-series NAME)]

-- 
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] Typed/Untyped cost reduction and experience

[JCG]

Sorry, there's no publicly available code involved with the project.

Seeing all the options, I believe that my favorite one is to type only at the 
border of my code, leaving the implementation in untyped Racket.  By dropping 
the contract cost, code still goes fast, and the borders are type-checked.

For the meantime, I'll be doing this on new code

#lang typed/racket[/unsafe maybe]

(module 'hundred-lines-of-untyped racket
   ...
   (define (my-function A B C)
   ...)))

(require/typed/provide 'hundred-lines-of-untyped
   [ my-function (-> NICE TYPED ARGS RESULT) ])

If I understand this correctly, the unsafe version will perform the same static 
checks on callers of the functions published by (provide) but not incur 
contract cost.







-- 
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: Time Series in Racket

[JCG]

We use C++ wrapped in both Racket and Python, a Racket data server front-ending 
numerous vendor data and Postgres on the backend.  While I am unaware of any 
correct public packages for time series work in finance, I've written several 
generations of a time series core in C, C++, Java fronted by custom DSLs, 
Python and Racket. I'd be happy to pass along my experience.

The algorithms and data structures are simple.  Finding usable data is 
difficult.

griffinish at gmail

-- 
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] Typed/Untyped cost reduction and experience

[JCG]

Having just converted a server process of about 1800 lines of untyped Racket to 
1900 lines of typed Racket, I'd like to make some comments

1) I highly suggest starting in Typed Racket if you are going to go end up 
there.  I made the mistake of writing it untyped and then retrofitting which 
clearly is the more difficult path.

2) The conversion caught one likely-to-happen-sometime bug, thank you.

3) The end-product appears to be a 50%-performance hybrid due to boundary 
contracts,  but ameliorated runtime-wise by utilizing the typed/racket/no-check 
language after it's all working in type checked mode.

4) I failed to create a valid new language with conditional inclusion of typed 
and no-check variants, but a command line or in-program conditional ability to 
disable types would permit an easy to accept morphing systems which need to 
gently attain 100% typed nature.   At the moment, I use a Unix shell script to 
doctor the #lang lines.  For instance 'raco -no-check exe ...' would really be 
nice after concluding that my slow hybrid is operating correctly.

5) When retrofitting, Dr Racket nicely points out errors, which in quantity 
should perhaps be limited to speed the retrofit cycle.  Being familiar with G++ 
template errors, I was not too shocked.  One thing that I learned was instead 
of attacking the first error which often was deeper in a function, it was more 
profitable to start at the outside, i.e. the function signature, and allow that 
information to imply further information.   I found that otherwise, I ended up 
with correct but superfluous annotations.

6) A few missing typed versions of libraries were what caused me to not start 
there, notably the lack of typed/db.

Thanks,
JG

-- 
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] Typed/Untyped cost reduction and experience

[JCG]

On Saturday, December 26, 2015 at 9:14:10 PM UTC-5, Asumu Takikawa wrote:
> 
> That way at least your types won't bitrot as much. Note that as the name
> indicates, this is potentially less safe than untyped Racket if the TR
> optimizer is on.
> 
> (you could also write a wrapper macro that globally enables/disables the
>  use of the unsafe imports & exports)
> 

Assuming that I'm reasonably sure from empirical tests that my contracts 
implied by the typed/untyped bridge are being satisfied, then this looks like a 
good idea.  

Thanks for this addition to the system.

-- 
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: Problems with 'provide'

[JCG]

looking at your output, it seems clear that the first (require "./util.rkt") 
was subjected to (read) but not evaluated.  Otherwise, the second line would be 
a prompt instead of the echoed s-expression.

Check your .racketrc file.   

-- 
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: reducing pauses with incremental GC

[JCG]

> 
> It was definitely less jerky from a user standpoint.

Interestingly, I tried this yesterday on a Debian desktop running on 2008 
2-core  iMac.  It was definitely feeling better with the PLT_INCREMENTAL_GC.  
Running the same image on the same machine underneath VMWare Fusion, the 
PLT_INCREMENTAL_GC was much less fluid than without the setting.  In other 
words, mileage appears to vary.  

-- 
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: reducing pauses with incremental GC

[JCG]

On Thursday, December 3, 2015 at 8:03:10 AM UTC-5, Matthew Flatt wrote:
> At Wed, 2 Dec 2015 16:23:34 -0800 (PST), JCG wrote:
> > On Wednesday, December 2, 2015 at 10:44:47 AM UTC-5, Matthew Flatt wrote:
> > > The development version of Racket now supports an incremental
> > > garbage-collection mode that can eliminate long pauses in a program.
> > > For example, incremental mode is useful for avoiding pauses in games
> > > and animations.
> > 
> > By chance then will the Dr. Racket environment itself honor the 
> > PLT_INCREMENTAL_GC variable and perhaps benefit from the less noticeable 
> > GC? 
> 
> Give it a try. I think you'll find that long pauses are reduced, but

Tried it with 50 GC observations with and without PLT_INCREMENTAL_GC. 

Without the environment variable, I had two major GCs of 1052ms and 1060ms and 
an average minor GC of 24ms.

With the environment variable set, I had one major GC of 488 ms and an average 
minor GC or 45ms.

It was definitely less jerky from a user standpoint.



-- 
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: reducing pauses with incremental GC

[JCG]

On Wednesday, December 2, 2015 at 10:44:47 AM UTC-5, Matthew Flatt wrote:
> The development version of Racket now supports an incremental
> garbage-collection mode that can eliminate long pauses in a program.
> For example, incremental mode is useful for avoiding pauses in games
> and animations.

By chance then will the Dr. Racket environment itself honor the 
PLT_INCREMENTAL_GC variable and perhaps benefit from the less noticeable GC? 

Thanks for a good addition.
JG

-- 
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] suggested default on warning

[JCG]

After having a silly runtime error of a missing argument, I wondered why arity 
wasn't checked (on hash-ref in my case).

Looking through old thread started by Roman Klochkov, I saw the answer to his 
and my identical question on arity checks.  I changed my logging to show in Dr 
Racket and included warnings on the list.  My immediate problem is solved.

My suggestion is that having a default of showing GC collection but not showing 
probable arity errors is misplaced.  For me, the GC information is noise.  
However, the arity check is very pertinent.  I understand that I can change the 
setting and I have.  However, I suspect that a review of those defaults would 
better assist the audience that is unlikely to have modified defaults.

Thanks for a wonderful environment.
John Griffin

-- 
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] adding meaning to boolean return values

[JCG]

Perhaps this would be a hassle for Typed-Racket maintainers, but there are many 
places where standard Racket library functions return boolean.  However, given 
the non-false nature of almost everything, certainly the code could be doubly 
useful and half the size while retaining boolean compatibility.

What reminded me of this was some code today:

(define (get-glue-library)  

  (or (getenv "GLUELIB")

  (let ((name "/tmp/somepath.so"))  

(and (file-exists? name)

 name   


If the file-exists? code were to return its file, then it would be

(define (get-glue-library)  

  (or (getenv "GLUELIB")

  (file-exists? "/tmp/somepath.so")))   


Then of course the ? suffix might seem less appropriate.

This is not a request for change, just an observation at how redundant my 
effort was to have to save the name of a file (to avoid typos) and to call two 
functions.   At least I do not have to

((let ((name "GLUELIB"))

   (and (getenv? name)  

(getenv name)))  



If I am missing some way to be more succinct while using the standard library 
calls, I would be appreciative of guidance.  

Thanks,
JG

-- 
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: make-phantom-bytes misunderstanding

[JCG]

Thanks for the fast response.  Yes, the pre-release appears to follow the 
phantom bytes hint just perfectly.   It appears to solidly park at 200 megs - a 
totally fine size.

If I used emoticons, this would be one of those times. 

Thanks much,
John

-- 
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] Text-compatible collapsing of S-expressions

[JCG]

The DrRacket editor allows me to nicely collapse s-expressions.  However, the 
format of the file ceases to be useful source text, rendering it useless in 
non-current-racket-GUI environments.

Have I overlooked something that allows me to make use of the code folding 
while maintaining compatibility with most other tools that expect normal source 
text?

Thanks in advance.
John

-- 
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: Naming for generalization of find-min and find-max?

[JCG]

On Sunday, October 11, 2015 at 6:24:57 PM UTC-4, Alex Knauth wrote:
> Hi,
> 
> The problem was naming it. We thought of `find-best` and 
> `find-most-relevant`, but `find-best` would be confusing when it's being used 
> to find the worst case, and `find-most-relevant` seems better but to wordy. 
> 
> 
> Do any of you have any ideas?
> 

I had the same question for a similar set of library functions not in racket).  
I chose 'most -  'most', e.g. most negative, most positive, most length.

-- 
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] Thanks for latest performance improvements

[JCG]

I just rewrote an existing C++ server in Racket in two days, dropping 2,000 C++ 
lines to 700 Racket lines.

The architecture of the previous server was based on fine planning and 
implementation, but quickly degraded from an 18-month succession of band-aids.  
Having laid out a replacement plan, I built a prototype in Racket.  The Racket 
implementation was really clear for me, but sadly about 20 times slower than 
its C++ predecessor.   I tracked half the problem to inefficient netstring 
parsing which brought me to 10 times.  The rest of the performance difference 
appeared to be networking throughput.

So, I was happy with this as a prototype, and it had cleared up enough logic 
that I could actually envision how to clean up everything C++-wise.  I realized 
that following the Racket work, I could probably drop my 2,000 C++ lines to 
1,500 nicer ones.  So, the prototyping had been useful.  

Then, something struck me.  I was running the default 6.1 Racket on my Debian 
8.  I thought that I'd see if anything changed performance-wise, so I placed 
Racket 6.2.900.17 into my /tmp directory and ran the server on that.

I have no idea what networking implementation facts have changed between 6.1 
and this snapshot, but it's now about 20% faster than the C++ server. The 
reimplemented service will remain in Racket.

Thanks to whomever it was that jacked up the networking speed.



-- 
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.