[racket-users] Typed Racket and struct

[Antonio Menezes Leitao]

Hi,

I've been using Typed Racket in the last few months and it has been an
interesting experience.

However, there are a few helpful features of "normal" Racket that are not
yet available in Typed Racket.

One of them is the ability to use #:constructor-name in struct type
definitions.

I used rename-out as a replacement but it is not the same thing and it has
other annoying effects.

So, my questions are:

1. Are there any plans to support #:constructor-name in Typed Racket?

2. Which techniques do you recommend to circumvent that lack
of #:constructor-name ?

Best regards,
António.

-- 
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] Help updating racket/function

[Alexis King]

Ah, that’s my package, and that issue is my mistake. I had a version exception 
for 6.2, but I was missing a version exception for 6.2.1. It should work on 
6.2.1 now. Try updating alexis-collections (or uninstalling/reinstalling it), 
and it pull the right version. Thanks for the report!

Alexis

> On Nov 19, 2015, at 10:44 AM, brendan  wrote:
> 
> I installed the package alexis-collections via DrRacket. The build process 
> reported problems with an unbound identifier, and after investigating I found 
> that my installation's racket/function module is missing a couple of things 
> that are in the current version on GitHub. However, DrRacket reports that 
> Racket is up-to-date and so are all of the packages. I still feel pretty lost 
> with respect to the whole Racket ecosystem (packages, collections, catalogs, 
> etc) so I'm not sure what I'm doing wrong. Any help would be greatly 
> appreciated.
> 
> -- 
> 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] Typed Racket and struct

[Antonio Menezes Leitao]

Hi,

On Thu, Nov 19, 2015 at 11:36 AM, WarGrey Gyoudmon Ju  wrote:

> 1. define structs in untyped racket;
> 2. (require/typed/provide) it with #:constructor-name option.
>
>
Thanks for the suggestion.

Meanwhile, I thought about a different approach. Here is one example:

(module test typed/racket
  (struct foo
([a : Real]
 [b : Integer]))
  (provide (except-out (struct-out foo) foo)
   (rename-out [foo new-foo])))

(require 'test)

(define f (new-foo 1.0 2))

(foo-a f)

(foo-b f)

Can you (or someone else) comment on the advantages of these two approaches?

Finally, can we define syntax to wrap both the module and the require? Is
it possible for a macro to expand into such combination of forms? My quick
experiments didn't produce the results I was expecting.

Best,
António.



> On Thu, Nov 19, 2015 at 5:11 PM, Antonio Menezes Leitao <
> antonio.menezes.lei...@ist.utl.pt> wrote:
>
>> Hi,
>>
>> I've been using Typed Racket in the last few months and it has been an
>> interesting experience.
>>
>> However, there are a few helpful features of "normal" Racket that are not
>> yet available in Typed Racket.
>>
>> One of them is the ability to use #:constructor-name in struct type
>> definitions.
>>
>> I used rename-out as a replacement but it is not the same thing and it
>> has other annoying effects.
>>
>> So, my questions are:
>>
>> 1. Are there any plans to support #:constructor-name in Typed Racket?
>>
>> 2. Which techniques do you recommend to circumvent that lack
>> of #:constructor-name ?
>>
>> Best regards,
>> António.
>>
>> --
>> 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 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] Help updating racket/function

[brendan]

I installed the package alexis-collections via DrRacket. The build process 
reported problems with an unbound identifier, and after investigating I found 
that my installation's racket/function module is missing a couple of things 
that are in the current version on GitHub. However, DrRacket reports that 
Racket is up-to-date and so are all of the packages. I still feel pretty lost 
with respect to the whole Racket ecosystem (packages, collections, catalogs, 
etc) so I'm not sure what I'm doing wrong. Any help would be greatly 
appreciated.

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

[Neil Van Dyke]

Brian Adkins wrote on 11/19/2015 07:08 PM:

The example that provided the initial motivation is extremely simple - process 
45M+ text records with some minor transformations (including computing a couple 
soundex values on first/last names). Racket came in at 2.4x faster than Ruby, 
but still CPU bound, and it really should be I/O bound, so I figure I'll 
process N records in parallel. But I'm really thinking more generally - I know 
I'll occasionally encounter these types of issues.


BTW, I don't know how much energy you've already put into 
hand-optimizing the Racket code for that example, but just a general 
comment for the list...  There are often big gains to be had through 
hand-optimizing.  For this particular example, if one is seeing lots of 
GC cost (which could be contributing to CPU-bound), and can't suppress 
GC for the duration of the run, one might start by focusing on reducing 
allocations (e.g., by reusing byte strings for read buffer, and maybe 
even using same buffer for writing after you look at the pipeline).  
Then, once I/O method is decided, profile and look at the operations and 
the pipeline (e.g., maybe you find it's a win to have Soundex routines 
working from zero-copy byte string I/O buffer directly, assuming 
single-byte chars and handling any non-ASCII/Latin-1 as they go).  In 
this example, a fast implementation might be somewhat closer to how 
you'd do it in C than a first-shot Racket implementation is, only it's 
still easier than C overall, and it works more smoothly with other 
Racket code than intermixing C and Racket does.


Neil V.

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

[Brian Adkins]

On Thursday, November 19, 2015 at 5:37:12 PM UTC-5, johnbclements wrote:
> > Any thoughts from folks that are FFI'ing from/to Racket and/or using a 
> > second language in the same system as Racket ?
> 
> My “thoughts" are more along the lines of cheerleading. I worked on Hygiene 
> for Rust, and I really want to see Rust succeed. I’ve built a tiny 
> proof-of-concept rust ffi interface that I describe at
> 
> http://www.brinckerhoff.org/blog/2013/03/29/embedding-rust-in-racket/
> 
> … but I can’t really comment on the difficulty of building larger interfaces. 
> I will say this, though: Rust will make you spend time at the front end, 
> satisfying the borrow-checker. The payoff comes later, when you don’t have to 
> debug all of those core dumps.
> 
> John

Thanks John - I came across your blog post soon after I started looking into 
Rust and bookmarked it for future reference. I have experienced needing to 
placate the compiler a bit which is reminiscent of my time with Haskell/OCaml - 
a little more front end loaded than Ruby/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.

Re: [racket-users] Rust vs. C as a complement to Racket?

[Brian Adkins]

On Thursday, November 19, 2015 at 7:45:45 PM UTC-5, Neil Van Dyke wrote:
> Brian Adkins wrote on 11/19/2015 07:08 PM:
> > The example that provided the initial motivation is extremely simple - 
> > process 45M+ text records with some minor transformations (including 
> > computing a couple soundex values on first/last names). Racket came in at 
> > 2.4x faster than Ruby, but still CPU bound, and it really should be I/O 
> > bound, so I figure I'll process N records in parallel. But I'm really 
> > thinking more generally - I know I'll occasionally encounter these types of 
> > issues.
> 
> BTW, I don't know how much energy you've already put into 
> hand-optimizing the Racket code for that example, but just a general 
> comment for the list...  There are often big gains to be had through 
> hand-optimizing.  For this particular example, if one is seeing lots of 
> GC cost (which could be contributing to CPU-bound), and can't suppress 
> GC for the duration of the run, one might start by focusing on reducing 
> allocations (e.g., by reusing byte strings for read buffer, and maybe 
> even using same buffer for writing after you look at the pipeline).  
> Then, once I/O method is decided, profile and look at the operations and 
> the pipeline (e.g., maybe you find it's a win to have Soundex routines 
> working from zero-copy byte string I/O buffer directly, assuming 
> single-byte chars and handling any non-ASCII/Latin-1 as they go).  In 
> this example, a fast implementation might be somewhat closer to how 
> you'd do it in C than a first-shot Racket implementation is, only it's 
> still easier than C overall, and it works more smoothly with other 
> Racket code than intermixing C and Racket does.
> 
> Neil V.

I did *some* hand optimizing. Here's the code for the soundex and some string 
helper functions I created:

https://gist.github.com/lojic/1deba97f2e2eb2fe3fc0

I fired up the profiler (in error trace mode) and worked on the critical paths. 
string-replace string-trim showed up. I hand rolled non-upcase-alpha and 
remove-zeros because they were faster than string-replace with regexes.

I'm sure more could be done, but I'd be a bit surprised if I can go from 2.4x 
to even 3x the speed of Ruby given the optimizing I've already done.

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.

Re: [racket-users] Rust vs. C as a complement to Racket?

[Brian Adkins]

On Thursday, November 19, 2015 at 6:25:19 PM UTC-5, Matthias Felleisen wrote:
> Brian, 
> 
> -- when you say "raw speed", do you need "Fortran" level speed for numerical 
> algorithms or just "somewhat faster than Racket, almost close to C"? If it's 
> the latter, Rust may work out for you. 

I would say more the latter - less than 2x of C speed.

> -- when you say you need many cores for your computations. That sounds like 
> very-raw speed, not just raw speed. This may call for C after all. 

The example that provided the initial motivation is extremely simple - process 
45M+ text records with some minor transformations (including computing a couple 
soundex values on first/last names). Racket came in at 2.4x faster than Ruby, 
but still CPU bound, and it really should be I/O bound, so I figure I'll 
process N records in parallel. But I'm really thinking more generally - I know 
I'll occasionally encounter these types of issues.

> -- then again, if it is just about trying to exploit the parallelism of your 
> computer when possible, why not use places (or futures) in Racket? Yes, 
> Rust's type system makes this a bit safer. It basically rules out race 
> conditions via its type system. But this one depends on your take of how much 
> you fear race conditions and how familiar you are with a mostly-functional 
> approach of our CML library, which in my experience reduces this danger, too.

Yes, re-implementing the Racket version with places is on my list, and I'll 
compare with the Rust or C multi-threaded version. I was getting ~ 10 MB/s I/O 
on my SSD in Racket, but I should be able to get ~ 70 MB/s, so even using 4 
cores may not be quite enough.

> -- if you opt for Rust, consider the callback problem. My (passive) 
> experience with lots of code that has to set up call backs from C to Rust, is 
> that this area is a bit problematic. I scanned John's blog post and didn't 
> see how he addressed that, though I didn't read his git repo. Perhaps there 
> are some examples there. And yes, in the end it's doable; it just seems to 
> require a lot of fiddling. 

In this specific case, I would probably just create a standalone program in the 
lower level language since it won't need much domain/business logic, so no FFI 
would be involved. In other cases, I'll definitely want to use FFI though, so 
if turns out that C is much better for FFI w/ Racket, that would influence me.

> -- finally, beware of the need to drop from Rust to unsafe Rust -- where the 
> type system just gives up the key innovations that Rust introduces. This is 
> especially noticable for callbacks, but even other code (see John's) tends to 
> include one or the other unsafe block. 
> 
> -- Matthias

Thanks - good things to consider.

-- 
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 and struct

[WarGrey Gyoudmon Ju]

On Fri, Nov 20, 2015 at 3:27 AM, Antonio Menezes Leitao <
antonio.menezes.lei...@ist.utl.pt> wrote:

> Hi,
>
> On Thu, Nov 19, 2015 at 11:36 AM, WarGrey Gyoudmon Ju <
> juzhenli...@gmail.com> wrote:
>
>> 1. define structs in untyped racket;
>> 2. (require/typed/provide) it with #:constructor-name option.
>>
>>
> Thanks for the suggestion.
>
> Meanwhile, I thought about a different approach. Here is one example:
>
> (module test typed/racket
>   (struct foo
> ([a : Real]
>  [b : Integer]))
>   (provide (except-out (struct-out foo) foo)
>(rename-out [foo new-foo])))
>
> (require 'test)
>
> (define f (new-foo 1.0 2))
>
> (foo-a f)
>
> (foo-b f)
>
> Can you (or someone else) comment on the advantages of these two
> approaches?
>

Generally speaking, Racket Struct is not only a compact data collection
(like a vector with fields accessors, benefits both compiler and human
readers), Struct itself also has their own properties and methods to define
generic interfaces which is widely known in Class-based System (ignoring
that Racket Class-based System is also implemented in terms of Struct, they
are different things but have same effects).

Currently, Typed Racket only treats Struct as the compact data collection,
therefore, if you want to take full advantages of Struct, defining it in
untyped module than requiring it in typed module is the only choice, but
not vice versa.

I never tried your approach in practice, and you have already known the
side effects. Nonetheless, if you don't like the untyped way. How about
just defining one more function to make its instance? In this way, you also
have a more flexible guard procedure (see #:guard option). Besides I just
cannot understand the design of #:auto and #:auto-value options, it's so
weird that almost makes nonsense.


>
> Finally, can we define syntax to wrap both the module and the require? Is
> it possible for a macro to expand into such combination of forms? My quick
> experiments didn't produce the results I was expecting.
>

I found it impossible too.


>
> Best,
> António.
>

-- 
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 and struct

[Asumu Takikawa]

On 2015-11-19 09:11:08 +, Antonio Menezes Leitao wrote:
>So, my questions are:
>1. Are there any plans to support #:constructor-name in Typed Racket?

I haven't tried to implement support for it, but I can't think of anything off
the top of my head that would make it difficult. I suspect we just haven't
gotten around to it.

Maybe we can support it for (add1 v6.3).

Cheers,
Asumu

-- 
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] Help updating racket/function

[brendan]

Outstanding, thank you.

On Thursday, November 19, 2015 at 2:52:52 PM UTC-5, Alexis King wrote:
> Ah, that’s my package, and that issue is my mistake. I had a version 
> exception for 6.2, but I was missing a version exception for 6.2.1. It should 
> work on 6.2.1 now. Try updating alexis-collections (or 
> uninstalling/reinstalling it), and it pull the right version. Thanks for the 
> report!

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

[Brian Adkins]

The more I dig into Racket, the more I like it. It seems like a perfect fit for 
both my personality and the type of applications I am, and will be, writing. 
For the vast majority of what I need to do, it's a great fit.

I do occasionally encounter a need for raw speed, so I'm looking for a 
complement to Racket for those few times when it's not fast enough. I chatted 
briefly about this on IRC the other day, but I thought I'd tap into the 
collective wisdom on the mailing list.

I'm open to suggestions, but I've tentatively narrowed the list down to Rust 
and C. I programmed in C/C++ for about a decade, then Java for a decade, and 
most recently in Ruby for a decade, so it's been a while since I was an expert 
C hacker, and my recent Ruby experience has lessened my polyglotness :)

If I were to do a *lot* of lower level coding, I think the niceties of Rust 
would win out over C, but I'm planning on doing most of my application coding 
in Racket, and only needing a lower level language for a few speedups, some 
ad-hoc file crunching programs, etc.. I like the memory safety Rust provides 
without giving up too much performance; the standard library seems fairly rich; 
the language features are fairly nice, etc.

Although I think there is a goal to reduce the amount of C code in Racket, I 
expect there will continue to be a fair amount for the foreseeable future, so 
getting my C chops back would allow me to possibly contribute in that area 
eventually (although I'd prefer to contribute Racket code). And there are some 
Schemes that compile down to C which would allow me to use them in some 
challenged environments (e.g. for Robotics, etc.), so renewing my C proficiency 
would be handy.

I think the FFI interaction between Racket & C may be smoother than between 
Rust & C, but that is conjecture.

Multi-core complicates things a bit. The specific program that motivated me to 
consider Rust or C is an easily parallellizeable program to parse & dump a file 
into a different format, and even though I wrote plenty of multi-threaded C 
code in the past, I'm almost positive this would be much more pleasant, and 
less error prone, in Rust. And given current CPU advances, I think multi-core 
is important for getting the most out of code these days.

Ultimately they're not mutually exclusive, but in the near term they are, I 
only have so much time.

Any thoughts from folks that are FFI'ing from/to Racket and/or using a second 
language in the same system as Racket ?

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

Re: [racket-users] Rust vs. C as a complement to Racket?

[Matthias Felleisen]

Brian, 

-- when you say "raw speed", do you need "Fortran" level speed for numerical 
algorithms or just "somewhat faster than Racket, almost close to C"? If it's 
the latter, Rust may work out for you. 

-- when you say you need many cores for your computations. That sounds like 
very-raw speed, not just raw speed. This may call for C after all. 

-- then again, if it is just about trying to exploit the parallelism of your 
computer when possible, why not use places (or futures) in Racket? Yes, Rust's 
type system makes this a bit safer. It basically rules out race conditions via 
its type system. But this one depends on your take of how much you fear race 
conditions and how familiar you are with a mostly-functional approach of our 
CML library, which in my experience reduces this danger, too. 

-- if you opt for Rust, consider the callback problem. My (passive) experience 
with lots of code that has to set up call backs from C to Rust, is that this 
area is a bit problematic. I scanned John's blog post and didn't see how he 
addressed that, though I didn't read his git repo. Perhaps there are some 
examples there. And yes, in the end it's doable; it just seems to require a lot 
of fiddling. 

-- finally, beware of the need to drop from Rust to unsafe Rust -- where the 
type system just gives up the key innovations that Rust introduces. This is 
especially noticable for callbacks, but even other code (see John's) tends to 
include one or the other unsafe block. 

-- Matthias






On Nov 19, 2015, at 5:37 PM, "'John Clements' via Racket Users" 
 wrote:

> 
>> On Nov 19, 2015, at 2:01 PM, Brian Adkins  wrote:
>> 
>> The more I dig into Racket, the more I like it. It seems like a perfect fit 
>> for both my personality and the type of applications I am, and will be, 
>> writing. For the vast majority of what I need to do, it's a great fit.
>> 
>> I do occasionally encounter a need for raw speed, so I'm looking for a 
>> complement to Racket for those few times when it's not fast enough. I 
>> chatted briefly about this on IRC the other day, but I thought I'd tap into 
>> the collective wisdom on the mailing list.
>> 
>> I'm open to suggestions, but I've tentatively narrowed the list down to Rust 
>> and C. I programmed in C/C++ for about a decade, then Java for a decade, and 
>> most recently in Ruby for a decade, so it's been a while since I was an 
>> expert C hacker, and my recent Ruby experience has lessened my polyglotness 
>> :)
>> 
>> If I were to do a *lot* of lower level coding, I think the niceties of Rust 
>> would win out over C, but I'm planning on doing most of my application 
>> coding in Racket, and only needing a lower level language for a few 
>> speedups, some ad-hoc file crunching programs, etc.. I like the memory 
>> safety Rust provides without giving up too much performance; the standard 
>> library seems fairly rich; the language features are fairly nice, etc.
>> 
>> Although I think there is a goal to reduce the amount of C code in Racket, I 
>> expect there will continue to be a fair amount for the foreseeable future, 
>> so getting my C chops back would allow me to possibly contribute in that 
>> area eventually (although I'd prefer to contribute Racket code). And there 
>> are some Schemes that compile down to C which would allow me to use them in 
>> some challenged environments (e.g. for Robotics, etc.), so renewing my C 
>> proficiency would be handy.
>> 
>> I think the FFI interaction between Racket & C may be smoother than between 
>> Rust & C, but that is conjecture.
>> 
>> Multi-core complicates things a bit. The specific program that motivated me 
>> to consider Rust or C is an easily parallellizeable program to parse & dump 
>> a file into a different format, and even though I wrote plenty of 
>> multi-threaded C code in the past, I'm almost positive this would be much 
>> more pleasant, and less error prone, in Rust. And given current CPU 
>> advances, I think multi-core is important for getting the most out of code 
>> these days.
>> 
>> Ultimately they're not mutually exclusive, but in the near term they are, I 
>> only have so much time.
>> 
>> Any thoughts from folks that are FFI'ing from/to Racket and/or using a 
>> second language in the same system as Racket ?
> 
> My “thoughts" are more along the lines of cheerleading. I worked on Hygiene 
> for Rust, and I really want to see Rust succeed. I’ve built a tiny 
> proof-of-concept rust ffi interface that I describe at
> 
> http://www.brinckerhoff.org/blog/2013/03/29/embedding-rust-in-racket/
> 
> … but I can’t really comment on the difficulty of building larger interfaces. 
> I will say this, though: Rust will make you spend time at the front end, 
> satisfying the borrow-checker. The payoff comes later, when you don’t have to 
> debug all of those core dumps.
> 
> John
> 
>> 
>> Thanks,
>> Brian
>> 
>> 
>> -- 
>> You received this message because you are 

[racket-users] Re: Configuration Files

[Christopher Walborn]

I appreciate all the responses. Time to do some reading and experimenting. At 
this point I've managed to read files and use regex to pull data into new 
variables or parameters I've set up, but I haven't gotten to the point of 
actually reading in racket data structures, so this gives me an angle on 
chiseling away at that.

Thanks,
Christopher

-- 
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 and struct

[WarGrey Gyoudmon Ju]

1. define structs in untyped racket;
2. (require/typed/provide) it with #:constructor-name option.

On Thu, Nov 19, 2015 at 5:11 PM, Antonio Menezes Leitao <
antonio.menezes.lei...@ist.utl.pt> wrote:

> Hi,
>
> I've been using Typed Racket in the last few months and it has been an
> interesting experience.
>
> However, there are a few helpful features of "normal" Racket that are not
> yet available in Typed Racket.
>
> One of them is the ability to use #:constructor-name in struct type
> definitions.
>
> I used rename-out as a replacement but it is not the same thing and it has
> other annoying effects.
>
> So, my questions are:
>
> 1. Are there any plans to support #:constructor-name in Typed Racket?
>
> 2. Which techniques do you recommend to circumvent that lack
> of #:constructor-name ?
>
> Best regards,
> António.
>
> --
> 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] Configuration Files

[WarGrey Gyoudmon Ju]

Yes, I like the idea of #lang info(#lang setup/infotab) which is highly
constrained, and it is an out-of-box solution.
It's better to have a (get-info/file filename.rkt) as an alternative to
(get-info/full infodir-path).


On Thu, Nov 19, 2015 at 7:32 AM, Neil Van Dyke  wrote:

> I generally second the idea of doing a configuration file format like
> "info.rkt" (but not using that particular filename, unless your program is
> tools for Racket development projects).
>
> An advantage of this format is that you then have a few different options
> for how to use the file.  Specifically, if the file format looks like
> Racket code, you can use it via `read`/`read-syntax` (while setting
> parameters for safety), via `dynamic-require`, or via `require`.
>
> And you can change your mind how to use the format later, without
> requiring end users to change the documented file format they use.
>
> If you eventually go to `dynamic-require` or `require`, then you can add
> more Racket language features to the "configuration file", and then it's an
> extensibility language, or your program is a domain-specific framework.
> This is also a good way to ease people into extension, and into using
> Racket.
>
> Neil V.
>
>
> --
> 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] Rust vs. C as a complement to Racket?

[Brian Adkins]

On Thursday, November 19, 2015 at 9:56:01 PM UTC-5, gustavo wrote:
> > I did *some* hand optimizing. Here's the code for the soundex and some 
> > string helper functions I created:
> >
> > https://gist.github.com/lojic/1deba97f2e2eb2fe3fc0
> >
> 
> I'm optimistic and I think that there is still some room for
> micro-optimizations (for example, replace the set!'s, but I didn't try
> yet).

I think the set!'s are what make it faster. Folks proposed various for 
statements which were much more elegant, but they were slower. I usually favor 
elegance over speed, and for the vast majority of my code, 
elegance/readability/etc. are more important, but this code takes hours to run, 
so speeding it up is helpful.

> But more important is:Do you want to preserve the general structure of the 
> code?
> 
> It has many small functions that are nice to write and debug, but each
> one creates an intermediate string. In this algorithm, most of the
> processing is character-by-character. So I think that most of the
> calculations can be merged in a megafunction that avoids most of the
> allocations.

Possibly, but profiling showed that various string functions were on the 
critical path.

> 
> Gustavo

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

[Gustavo Massaccesi]

> I did *some* hand optimizing. Here's the code for the soundex and some string 
> helper functions I created:
>
> https://gist.github.com/lojic/1deba97f2e2eb2fe3fc0
>

I'm optimistic and I think that there is still some room for
micro-optimizations (for example, replace the set!'s, but I didn't try
yet).

But more important is:Do you want to preserve the general structure of the code?

It has many small functions that are nice to write and debug, but each
one creates an intermediate string. In this algorithm, most of the
processing is character-by-character. So I think that most of the
calculations can be merged in a megafunction that avoids most of the
allocations.

Gustavo

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

[Brian Adkins]

On Thursday, November 19, 2015 at 11:08:07 PM UTC-5, Brian Adkins wrote:
> On Thursday, November 19, 2015 at 9:56:01 PM UTC-5, gustavo wrote:
> > > I did *some* hand optimizing. Here's the code for the soundex and some 
> > > string helper functions I created:
> > >
> > > https://gist.github.com/lojic/1deba97f2e2eb2fe3fc0
> > >
> > 
> > I'm optimistic and I think that there is still some room for
> > micro-optimizations (for example, replace the set!'s, but I didn't try
> > yet).
> 
> I think the set!'s are what make it faster. Folks proposed various for 
> statements which were much more elegant, but they were slower. I usually 
> favor elegance over speed, and for the vast majority of my code, 
> elegance/readability/etc. are more important, but this code takes hours to 
> run, so speeding it up is helpful.
> 
> > But more important is:Do you want to preserve the general structure of the 
> > code?
> > 
> > It has many small functions that are nice to write and debug, but each
> > one creates an intermediate string. In this algorithm, most of the
> > processing is character-by-character. So I think that most of the
> > calculations can be merged in a megafunction that avoids most of the
> > allocations.
> 
> Possibly, but profiling showed that various string functions were on the 
> critical path.
> 
> > 
> > Gustavo

FWIW here's some profile output:

https://gist.github.com/lojic/f1ea6371155db861e2cd

and the output from time on one run showing gc time

cpu time: 2908 real time: 2915 gc time: 84

-- 
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] How to get information about where an error occurs, in a stack trace context?

[thomas.lynch]

I have a related question.  I turned on error trace using the command line Robby
suggested, but it doesn't give me a trace, but rather just the call point and 
error function.  Here is an example, the trace should be f -> gg -> g -> hh -> 
h then bang, the error.   But instead Racket shows me f -> + bang,  "in context 
of h".  But which 'h' it is called many times (and in a big project many many 
times).

How do you turn on tracing?  Is there another switch, or if I go interactive is 
there a command which will give me the trace?


;; bt2-ex-fun2.rkt:
;;
  #lang racket

  (define (h x y) (+ x y))

  (define (hh x y) (h x y))

  (define (f x y)
(gg x y)
)

  (define (gg x y) 
(define z 7)
(set! z (h 5 0))
(g (- x z) y)
)

  (define zz 5)

  (define (g x y)
(hh (+ x (h zz 0)) y)
)

  (f 3 5)
  (f 3 'a)

  #| result:

  §> racket -l errortrace -t bt2-ex-fun2.rkt 
  8
  +: contract violation
expected: number?
given: 'a
argument position: 2nd
other arguments...:
 3
errortrace...:
 /home/deep/3_doc/racket_err_mess/bt2-ex-fun2.rkt:3:16: (+ x y)
 /home/deep/3_doc/racket_err_mess/bt2-ex-fun2.rkt:24:0: (f 3 (quote a))
context...:
 /home/deep/3_doc/racket_err_mess/bt2-ex-fun2.rkt:3:0: h
 /home/deep/3_doc/racket_err_mess/bt2-ex-fun2.rkt: [running body]

  §> 

  |#














On Thursday, November 12, 2015 at 5:19:20 PM UTC, Matthew Flatt wrote:
> At Sun, 8 Nov 2015 21:56:04 -0500, Ben Lerner wrote:
> > 
> > On 11/8/2015 9:18 PM, Nota Poin wrote:
> > >> Or if you insist on command line usage, use error trace.
> > > What's wrong with command line usage? Anyway, I was going to say this:
> > >
> > > http://docs.racket-lang.org/errortrace/using-errortrace.html
> > >
> > > That seems to enable stack traces that work.
> > >
> > Relatedly, is there a way to use this stacktrace mechanism with 
> > scribble?  That is, can I write `scribble -l errortrace  > files>` or `racket -l errortrace  
> > `, or would that not work out for some reason?
> 
> For errors while a document is constructed, just running
> 
>  racket -l errortrace -t 
> 
> would work, since a Scribble document is a Racket program.
> 
> 
> For an error that happens only during rendering, you could use
> 
>  racket -l errortrace -l scribble/run 
> 
> since the `scribble` program just runs the `scribble/run` module.
> 
> I'm not sure why it's `scribble/run` instead of just `scribble`, and
> maybe it's worth adding a `scribble` module as an alias. I'll think
> about that more, in case there was a reason that I've forgotten.

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

[Brian Adkins]

On Thursday, November 19, 2015 at 11:18:16 PM UTC-5, Brian Adkins wrote:
> On Thursday, November 19, 2015 at 11:08:07 PM UTC-5, Brian Adkins wrote:
> > On Thursday, November 19, 2015 at 9:56:01 PM UTC-5, gustavo wrote:
> > > > I did *some* hand optimizing. Here's the code for the soundex and some 
> > > > string helper functions I created:
> > > >
> > > > https://gist.github.com/lojic/1deba97f2e2eb2fe3fc0
> > > >
> > > 
> > > I'm optimistic and I think that there is still some room for
> > > micro-optimizations (for example, replace the set!'s, but I didn't try
> > > yet).
> > 
> > I think the set!'s are what make it faster. Folks proposed various for 
> > statements which were much more elegant, but they were slower. I usually 
> > favor elegance over speed, and for the vast majority of my code, 
> > elegance/readability/etc. are more important, but this code takes hours to 
> > run, so speeding it up is helpful.
> > 
> > > But more important is:Do you want to preserve the general structure of 
> > > the code?
> > > 
> > > It has many small functions that are nice to write and debug, but each
> > > one creates an intermediate string. In this algorithm, most of the
> > > processing is character-by-character. So I think that most of the
> > > calculations can be merged in a megafunction that avoids most of the
> > > allocations.
> > 
> > Possibly, but profiling showed that various string functions were on the 
> > critical path.
> > 
> > > 
> > > Gustavo
> 
> FWIW here's some profile output:
> 
> https://gist.github.com/lojic/f1ea6371155db861e2cd
> 
> and the output from time on one run showing gc time
> 
> cpu time: 2908 real time: 2915 gc time: 84

And for completeness, I added the parser.rkt file to the gist, so all 3 files 
are there now:

https://gist.github.com/lojic/1deba97f2e2eb2fe3fc0

I think I'll code up a multi-threaded Rust or C version and see how the numbers 
compare, and then the Racket version with places.

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