[racket-users] Re: Looking for transducer early-adopters

[Jack Firth]

That's perfect! Thank you very much Alex.

On Friday, November 15, 2019 at 5:15:10 AM UTC-8, Alex Harsanyi wrote:
>
>
> I'm not sure if this would be useful to you, but, as part of writing my 
> tzgeolookup package, I wrote a blog post exploring the performance of 
> different ways in which the underlying data is organized.  As a result of 
> that, I have a repository with 10 variants of the same program using 
> different strategies, and these programs are all instrumented, so running 
> them will run a test suite and print out the time taken by each procedure.  
> You could implement a variant using transducers and compare it with all the 
> others.
>
> The repository is here: https://github.com/alex-hhh/time-zone-lookup-tests, 
> and the blog post explains how the hole thing works:  
> https://alex-hhh.github.io/2019/08/timezone-lookup.html
>
> The final package uses vectors, so I am not sure that would be useful in 
> converting it to transducers, but if you want to look at it, it is here: 
> https://github.com/alex-hhh/tzgeolookup
>
> Alex.
>
>
>
> On Friday, November 15, 2019 at 3:18:23 PM UTC+8, Jack Firth wrote:
>>
>> Hello all! I'd like to get Rebellion's 
>>  transducer 
>>  and reducer 
>>  libraries up to 
>> feature parity with Racket's ordinary list-processing functions. So I'm 
>> looking for people interested in migrating some of their open-source Racket 
>> code to use transducers instead of using map / filter / fold / append-map / 
>> etc. Even just pointing me to some of your code on GitHub that does list 
>> processing would be a great help, since I could attempt to migrate it 
>> myself and see if there's any functionality I'm missing that stands in the 
>> way of migrating. Huge bonus points if your code has benchmarks I can run, 
>> so I can compare the performance of manual list processing v.s. Rebellion 
>> stream processing v.s. optimized for loops.
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/9ea24052-b090-4f74-9adf-1c4d52c13049%40googlegroups.com.

[racket-users] symlink to raco changes its behavior?

['John Clements' via users-redirect]

I’ve been testing the release version of racket for a few weeks now, and I 
notice a strange difference between using the “raco” binary that’s part of the 
distribution and using a symlink to that binary. Specifically, calling raco 
setup always requires an explicit ‘-l’ when I use the symlink. When I provide 
the path to raco explicitly, it works fine without the -l. Attached see a 
transcript that shows the problem. I just want to make sure that … this is 
expected behavior?

John


```
# here’s the symlink:
hardy:/tmp/moss clements> ls -ld ~/bin/nuraco
lrwxr-xr-x  1 clements  staff  40 Oct 15 11:30 /Users/clements/bin/nuraco -> 
/Applications/Racket v7.4.0.902/bin/raco
# calling it with an explicit path works fine:
hardy:/tmp/moss clements> /Applications/Racket\ v7.4.0.902/bin/raco setup 
csse-scheduling
raco setup: version: 7.4.0.902
raco setup: platform: x86_64-macosx [3m]
raco setup: target machine: racket
raco setup: installation name: 7.4.0.902
raco setup: variants: 3m
raco setup: main collects: /Applications/Racket v7.4.0.902/collects
raco setup: collects paths: 
raco setup:   /Users/clements/Library/Racket/7.4.0.902/collects
raco setup:   /Applications/Racket v7.4.0.902/collects
raco setup: main pkgs: /Applications/Racket v7.4.0.902/share/pkgs
raco setup: pkgs paths: 
raco setup:   /Applications/Racket v7.4.0.902/share/pkgs
raco setup:   /Users/clements/Library/Racket/7.4.0.902/pkgs
raco setup: links files: 
raco setup:   /Applications/Racket v7.4.0.902/share/links.rktd
raco setup:   /Users/clements/Library/Racket/7.4.0.902/links.rktd
raco setup: main docs: /Applications/Racket v7.4.0.902/doc
raco setup: --- updating info-domain tables ---[16:31:56]
raco setup: --- pre-installing collections --- [16:31:56]
raco setup: --- installing foreign libraries ---   [16:31:56]
raco setup: --- installing shared files ---[16:31:56]
raco setup: --- compiling collections ---  [16:31:56]
raco setup: --- parallel build using 8 jobs ---[16:31:56]
raco setup: 7 making: /csse-scheduling/csse-scheduling (CSSE Scheduling 
Support)
raco setup: 7 making: /csse-scheduling/csse-scheduling/progress
raco setup: --- creating launchers --- [16:31:57]
raco setup: --- installing man pages ---   [16:31:57]
raco setup: --- building documentation --- [16:31:57]
raco setup: 2 skipping: /distro-build-doc/distro-build.scrbl
raco setup: rendering: 
/csse-scheduling/csse-scheduling/csse-scheduling.scrbl
WARNING: collected information for key multiple times: '(exporting-libraries 
#f); values: '(canonicalize) '(types)
WARNING: collected information for key multiple times: '(exporting-packages 
#f); values: '() '()
WARNING: collected information for key multiple times: '(exporting-libraries 
#f); values: '(types) '(qtr-math)
WARNING: collected information for key multiple times: '(exporting-packages 
#f); values: '() '()
raco setup: --- installing collections --- [16:32:02]
raco setup: --- post-installing collections ---[16:32:02]
# calling it using the symlink doesn’t work:
hardy:/tmp/moss clements> nuraco setup csse-scheduling
open-input-file: cannot open input file
  path: /tmp/moss/csse-scheduling
  system error: No such file or directory; errno=2
  context...:
   /Applications/Racket v7.4.0.902/collects/setup/unpack.rkt:262:2: unpack7
   /Applications/Racket v7.4.0.902/collects/setup/setup-core.rkt:287:13: 
for-loop
   /Applications/Racket v7.4.0.902/collects/setup/setup-core.rkt:72:0: 
setup-core
   "/Applications/Racket v7.4.0.902/collects/setup/main.rkt": [running body]
   temp37_0
   for-loop
   run-module-instance!125
   "/Applications/Racket v7.4.0.902/collects/raco/main.rkt": [running body]
   temp37_0
   for-loop
   run-module-instance!125
   perform-require!78
hardy:/tmp/moss clements> 
```

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/81830d2b-c734-481e-8caa-657c7f89eac9%40mtasv.net.

Re: [racket-users] Re: raco distribute and runtime paths, conditioned on whether a package was installed at compile time

[James Platt]

On Nov 12, 2019, at 10:13 PM, Matthew Flatt wrote:

>> Although you can find the files using `find-share-dir` and/or
>> `find-user-share-dir`, adding a 'share mode to `define-runtime-path`
>> would make it possible for `raco distribute` to find and carry along a
>> directory/file when it's present, the same as 'so mode does.
> 
> Added.


Would this now be the preferred method to include a copy of the SQLite library. 
required by the DB module, to your distribution?  The software I am working on 
requires a newer version of SQLite than is included in at least some of the 
operating systems we want to support and it's too much to expect end users to 
install it themselves.  

https://docs.racket-lang.org/db/notes.html?q=sqlite#%28part._sqlite3-requirements%29

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5F0EC3D9-1D58-426D-9D00-984560CF85B4%40biomantica.com.

Re: [racket-users] Problem building racket in-place

['Reuben Thomas' via Racket Users]

On Thu, 14 Nov 2019 at 19:59, Reuben Thomas  wrote:

> On Thu, 14 Nov 2019 at 12:51, Matthew Flatt  wrote:
>
>> At Wed, 13 Nov 2019 21:58:24 +, "'Reuben Thomas' via Racket Users"
>> wrote:
>> > While looking into implementing this, I discovered that
>> `racket/src/start/
>> > configure.ac`, which seems to have been introduced with the
>> introduction of
>> > CS, is not generated from racket/src/ac/*.m4, while all the other
>> > configure.ac's are.
>> >
>> > I guess this explains why the fix to `src/ac/path.m4` in commit
>> a56c984db0
>> > (inter alia) has not been applied to `start/configure.ac`?
>> >
>> > Since as far as I can tell, the putative `--disable-prefix` needs to be
>> > implemented in both `start/configure.ac` and `ac/path{,_arg}.m4`, I
>> thought
>> > it was worth sorting this out before trying to attempt the fix.
>>
>> Yes, it's definitely a mistake that "start/configure.ac" doesn't use
>> "src/ac/path.m4". (I must have lost track of that part when creating
>> "start/configure.ac" and other files out of the old single
>> "configure.ac".)
>>
>> A repair for that as part of adding `--disable-prefix` would be very
>> welcome.
>>
>
> I will look into that.
>

I've looked into it and I can't work out what start/*.ac are used. Having
read the various README.txt files and grepped around, I tried removing them
(start/configure.ac and start/install2.ac) and it didn't seem to prevent a
complete build from git checkout.

However, I see that some generated files like various "configure"s are
checked in, so maybe I'm overlooking something, a buried generated
reference to those files? (But I can't find install2 mentioned anywhere!)

-- 
https://rrt.sc3d.org

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAOnWdogvQBx%3DAx8O4M0nB1s%2BUSFT_W3ktqFyfq%2B4-6e0v%3D%3D6Ew%40mail.gmail.com.

[racket-users] Vulkan integration: Contributors Update

[Sage Gerard]

New update on the Vulkan collection: 
https://sagegerard.com/racket-vulkan-contributors-update.html

High points:

- A CLI is now available to control code generators and Vulkan specifications. 
You can now generate Racket bindings that don't need a code dependency on the 
collection, and can keep up with Vulkan even if the collection is out of date.
- There are now enough things to do that it's getting hard to prioritize. My 
focus recently has been maintainability/stability, with passive effort on a 
vulkan-tutorial.com port. I'll be asking the author to feature the example 
alongside the Rust variant of the tutorial.
- A contributor guide has been added to the docs.

Inspiration is kicking in. #lang for system requirements, shaders, and assets, 
oh my!

~slg

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/yNN1RTqu4C4eBNOr1Fl6X3MVQqXYhVzvHwZe82qlPLKEqBEJ7wI7U1-CpeidxukqdVjEVT1tg7EPUseM9NZSy_XLUDFsCMsXOprdJLpC5nE%3D%40sagegerard.com.

[racket-users] Re: Looking for transducer early-adopters

[Alex Harsanyi]

I'm not sure if this would be useful to you, but, as part of writing my 
tzgeolookup package, I wrote a blog post exploring the performance of 
different ways in which the underlying data is organized.  As a result of 
that, I have a repository with 10 variants of the same program using 
different strategies, and these programs are all instrumented, so running 
them will run a test suite and print out the time taken by each procedure.  
You could implement a variant using transducers and compare it with all the 
others.

The repository is here: https://github.com/alex-hhh/time-zone-lookup-tests, 
and the blog post explains how the hole thing works:  
https://alex-hhh.github.io/2019/08/timezone-lookup.html

The final package uses vectors, so I am not sure that would be useful in 
converting it to transducers, but if you want to look at it, it is here: 
https://github.com/alex-hhh/tzgeolookup

Alex.



On Friday, November 15, 2019 at 3:18:23 PM UTC+8, Jack Firth wrote:
>
> Hello all! I'd like to get Rebellion's 
>  transducer 
>  and reducer 
>  libraries up to 
> feature parity with Racket's ordinary list-processing functions. So I'm 
> looking for people interested in migrating some of their open-source Racket 
> code to use transducers instead of using map / filter / fold / append-map / 
> etc. Even just pointing me to some of your code on GitHub that does list 
> processing would be a great help, since I could attempt to migrate it 
> myself and see if there's any functionality I'm missing that stands in the 
> way of migrating. Huge bonus points if your code has benchmarks I can run, 
> so I can compare the performance of manual list processing v.s. Rebellion 
> stream processing v.s. optimized for loops.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5df506a6-fa4c-4fa9-8897-998aa8d249a1%40googlegroups.com.