Re: [racket-users] How to change package name on the package index?

2020-06-05 Thread Siddhartha Kasivajhula
I'm pleased to report that the "rename swap" of Originalname ->
Originalname-x -> originalname worked like a charm :) It also preserved the
metadata. Also, the dependent packages built successfully within about an
hour of the upstream rename. Thank you both for your suggestions and input.

If anyone has been using the "Relation" package, please use "relation" from
now on.

I've reported this issue here
<https://github.com/racket/pkg-index/issues/26>.




On Fri, Jun 5, 2020 at 12:41 AM Tony Garnock-Jones <
to...@leastfixedpoint.com> wrote:

> I think the package name system is case-insensitive (??) but
> case-preserving (definitely), and certainly objects to trying to create two
> packages that differ only in case.
>
> So renaming from FOO to foo won't work, because it considers this an
> attempt to overwrite an existing package. I think. We could probably change
> that?
>
> But here's a trick: try renaming FOO to FOO-x, and then to foo. That might
> work.
>
>
> On Friday, June 5, 2020 at 5:59:03 AM UTC+2, Siddhartha Kasivajhula wrote:
>>
>> ...@Alexis King , let's say I add the new package with the lowercase
>> name but other metadata identical to the old one, including the github repo
>> and the collection name. I would then update everything I care about to use
>> the new package and then wait for a day or two for the docs to show up. At
>> that point, how would the documentation server handle the fact that two
>> packages provide identical top-level collections? Would that be OK? Not
>> sure if it matters that this is a top-level collection name.
>>
>>
>>
>>
>> On Thu, Jun 4, 2020 at 8:32 PM Siddhartha Kasivajhula 
>> wrote:
>>
>>> OK, that's a good idea. I guess that still means it would lose the
>>> metadata, correct? That seems less than ideal, but I suppose it's more of
>>> an aesthetic concern.
>>>
>>> Re: the broader case-sensitivity consideration, for anyone interested in
>>> additional context, it looks like the python package index is case
>>> insensitive
>>> <https://stackoverflow.com/questions/26503509/is-pypi-case-sensitive>,
>>> while Ruby gems are case sensitive
>>> <https://guides.rubygems.org/name-your-gem/>, although it looks like
>>> capital letters are now disallowed
>>> <https://github.com/rubygems/rubygems.org/pull/481> following
>>> discussions including this one
>>> <https://github.com/rubygems/rubygems.org/issues/378>.
>>>
>>>
>>> On Thu, Jun 4, 2020 at 7:41 PM Alexis King  wrote:
>>>
>>>> On Jun 4, 2020, at 21:23, Siddhartha Kasivajhula 
>>>> wrote:
>>>>
>>>> I'd prefer to avoid that since (1) it would lose the package metadata
>>>> and (2) it could be off the package index for up to a day (the package
>>>> index refresh cycle) during which time other packages depending on it would
>>>> be broken
>>>>
>>>>
>>>> This isn’t quite right: it’s true that the pkg-build service only runs
>>>> once every 24 hours, but the only thing that depends on that is built
>>>> documentation. The actual package index is refreshed much more rapidly—on
>>>> the order of minutes. You wouldn’t have to wait very long at all to update
>>>> other packages.
>>>>
>>>> But even if you did, it wouldn’t matter, because there’s an easier
>>>> solution: add your package under the new name *before* you delete the
>>>> old name. Then you can delete the old name once you’ve ensured that
>>>> everything you care about is updated. It’s perhaps a bit strange to have
>>>> the same package simultaneously indexed under two different names, but it
>>>> shouldn’t cause any trouble.
>>>>
>>>> Alexis
>>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/7a1060e0-40ff-44d2-b432-8aa883e676a5o%40googlegroups.com
> <https://groups.google.com/d/msgid/racket-users/7a1060e0-40ff-44d2-b432-8aa883e676a5o%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CACQBWF%3DKB7TiRT7wAjtxBYQcDFKt2m3hZMkspyhYxs3dQ5WnCA%40mail.gmail.com.


Re: [racket-users] How to change package name on the package index?

2020-06-04 Thread Siddhartha Kasivajhula
@Alexis King  , let's say I add the new package with
the lowercase name but other metadata identical to the old one, including
the github repo and the collection name. I would then update everything I
care about to use the new package and then wait for a day or two for the
docs to show up. At that point, how would the documentation server handle
the fact that two packages provide identical top-level collections? Would
that be OK? Not sure if it matters that this is a top-level collection name.




On Thu, Jun 4, 2020 at 8:32 PM Siddhartha Kasivajhula 
wrote:

> OK, that's a good idea. I guess that still means it would lose the
> metadata, correct? That seems less than ideal, but I suppose it's more of
> an aesthetic concern.
>
> Re: the broader case-sensitivity consideration, for anyone interested in
> additional context, it looks like the python package index is case
> insensitive
> <https://stackoverflow.com/questions/26503509/is-pypi-case-sensitive>,
> while Ruby gems are case sensitive
> <https://guides.rubygems.org/name-your-gem/>, although it looks like
> capital letters are now disallowed
> <https://github.com/rubygems/rubygems.org/pull/481> following discussions
> including this one <https://github.com/rubygems/rubygems.org/issues/378>.
>
>
> On Thu, Jun 4, 2020 at 7:41 PM Alexis King  wrote:
>
>> On Jun 4, 2020, at 21:23, Siddhartha Kasivajhula 
>> wrote:
>>
>> I'd prefer to avoid that since (1) it would lose the package metadata and
>> (2) it could be off the package index for up to a day (the package index
>> refresh cycle) during which time other packages depending on it would be
>> broken
>>
>>
>> This isn’t quite right: it’s true that the pkg-build service only runs
>> once every 24 hours, but the only thing that depends on that is built
>> documentation. The actual package index is refreshed much more rapidly—on
>> the order of minutes. You wouldn’t have to wait very long at all to update
>> other packages.
>>
>> But even if you did, it wouldn’t matter, because there’s an easier
>> solution: add your package under the new name *before* you delete the
>> old name. Then you can delete the old name once you’ve ensured that
>> everything you care about is updated. It’s perhaps a bit strange to have
>> the same package simultaneously indexed under two different names, but it
>> shouldn’t cause any trouble.
>>
>> Alexis
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CACQBWF%3DQOv8ixdu_jXDbFJiHFt7Dc0f0SGTtgz0R8pGOFfDymA%40mail.gmail.com.


Re: [racket-users] How to change package name on the package index?

2020-06-04 Thread Siddhartha Kasivajhula
OK, that's a good idea. I guess that still means it would lose the
metadata, correct? That seems less than ideal, but I suppose it's more of
an aesthetic concern.

Re: the broader case-sensitivity consideration, for anyone interested in
additional context, it looks like the python package index is case
insensitive
<https://stackoverflow.com/questions/26503509/is-pypi-case-sensitive>,
while Ruby gems are case sensitive
<https://guides.rubygems.org/name-your-gem/>, although it looks like
capital letters are now disallowed
<https://github.com/rubygems/rubygems.org/pull/481> following discussions
including this one <https://github.com/rubygems/rubygems.org/issues/378>.


On Thu, Jun 4, 2020 at 7:41 PM Alexis King  wrote:

> On Jun 4, 2020, at 21:23, Siddhartha Kasivajhula 
> wrote:
>
> I'd prefer to avoid that since (1) it would lose the package metadata and
> (2) it could be off the package index for up to a day (the package index
> refresh cycle) during which time other packages depending on it would be
> broken
>
>
> This isn’t quite right: it’s true that the pkg-build service only runs
> once every 24 hours, but the only thing that depends on that is built
> documentation. The actual package index is refreshed much more rapidly—on
> the order of minutes. You wouldn’t have to wait very long at all to update
> other packages.
>
> But even if you did, it wouldn’t matter, because there’s an easier
> solution: add your package under the new name *before* you delete the old
> name. Then you can delete the old name once you’ve ensured that everything
> you care about is updated. It’s perhaps a bit strange to have the same
> package simultaneously indexed under two different names, but it shouldn’t
> cause any trouble.
>
> Alexis
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CACQBWFns9%2BMXSNhrV8XuAr3%3DN7Nx1Hk2%3Def%3DkFVX11D3whFixg%40mail.gmail.com.


[racket-users] How to change package name on the package index?

2020-06-04 Thread Siddhartha Kasivajhula
A little while ago I uploaded a package to the package index and entered a
Titlecase name for it. I've since learned that this becomes the identifier
for the package that will be used by raco from that point on (as opposed to
being used only on the package description page, as I assumed then). I'd
like to change this to be a lowercase name since (1) that corresponds to
the collection name, (2) using the lowercase name in raco, or to indicate
it as a dependency in info.rkt, currently results in the package not being
found, and (3) during local development, the package is hosted at a local
directory with a lowercase name, per UNIX convention, making local raco
interaction awkward (the info.rkt dependency needs to be titlecase on
origin, but lowercase locally).

Is there a way to change the name on the package index? "Editing" the
package and changing the name to lowercase doesn't work ("Save failed"). As
far as I can tell I should be able to delete the package and re-create it
under the lowercase name, but I'd prefer to avoid that since (1) it would
lose the package metadata and (2) it could be off the package index for up
to a day (the package index refresh cycle) during which time other packages
depending on it would be broken (I realize they may break anyway if I
change the name, but at least I'd be able to fix dependencies I control
immediately, and I'm not sure anyone else is using this package directly
anyway).

Aside from my particular conundrum, I'm wondering why package names are
case sensitive to begin with, and if it might mitigate confusion if they
were case insensitive.

Any suggestions or thoughts? 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CACQBWFmjGG%2BNLDGU7FH9%2BrkTrWWo_baEROAovK%3DLzc4vPwvadw%40mail.gmail.com.


[racket-users] Generators vs streams (incl. new library)

2020-04-28 Thread Siddhartha Kasivajhula
Hi folks,
Here is a by-no-means definitive, and yet hopefully useful library for
working with generators:

https://docs.racket-lang.org/generator-util/index.html

In writing this library, I thought about the cases in which one might use a
generator vs a stream in practice. Since Racket provides such great
interfaces for working with streams, why not just always use them, and
maybe convert generators into streams using utilities like in-producer
?
It somehow felt wrong to do that, so I did some digging to see what people
might have said on the subject. I found a paper
 about it, but it
didn't really get into this particular point.

In the end I seemed to converge on that while streams are great for lazy
semantics in general, generators are a more natural fit when, in addition
to requiring lazy semantics:
1. We are working with state and side effects (although of course there's
nothing except good sense preventing us from writing streams that deal in
side effects), or
2. In cases where function semantics are more natural, rather than sequence
semantics, and finally, and probably the most important
3. When we need constant memory guarantees, for instance, while processing
large datasets for some "big data" style task. For this last point, since
streams memoize return values
, their
memory requirements should grow linearly, is that right?

Anyway, whatever the reason one might use them, it just felt like working
with generators could be a little more convenient, hence this library.
There are 2 main caveats with using these utilities: (1) they don't support
coroutines, i.e. cases where you need to send data to an "online"
generator, vs just consuming from it (does anyone know if there is a way to
do generator delegation in Racket, like in python
?), and (2) the
provided "constructors" aren't lazy, so they are best used to manipulate
existing generators rather than truly construct generators from scratch for
production usecases (not sure this pattern of usage would ever really come
up, but just for symmetry with e.g. streams).

Finally, for reference, quickcheck
 and rackcheck
 also seem to provide
some useful generator-related utilities (not sure if they are limited to
testing usecases).

-Sid

-- 
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/CACQBWFmG9pfZwk7qr-gGXPgiJgpNekgK2MVGHRQqSUeZT1XDRA%40mail.gmail.com.


[racket-users] Lightweight, lazy trees (new package)

2020-04-21 Thread Siddhartha Kasivajhula
Hi folks,
Here is a new package providing lightweight, general purpose utilities for
working with tree-structured data:

https://docs.racket-lang.org/lazytree/

It allows you to take any data exhibiting tree structure and lazily
construct a stream representation of it using functions that presumably
already exist in your application, if the data indeed already
possesses tree structure.

The library leverages the corresponding tree structure of nested lists
(streams) to perform standard operations on data that has such structure,
for instance, providing operations analogous to map, filter, and fold, for
trees and with lazy semantics.

The laziness is inherited from the collection utilities in the excellent
data/collection 
library, and more generally, Racket streams
.

Enjoy,
-Sid

-- 
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/CACQBWF%3D5eQCcZZ8rQerNpeuzcxqYUpRxe5wtr1Rx_aSmOCh3JA%40mail.gmail.com.


Re: [racket-users] how to adapt BC code for Racket CS?

2020-04-17 Thread Siddhartha Kasivajhula
I've been regularly running "smoke" benchmarks for the relation
 library, and
just updated from Racket 7.5 (BC) to Racket CS 7.6. In case the data is
useful to anybody, here are the before/after times. These benchmarks
exercise elementary operations like comparisons for equality and order,
function composition, type transformations, algebraic composition of
numbers, strings, and so on. On these benchmarks, Racket CS seems to be
faster across the board:

Equivalence relations:
BC: 529ms
CS: 444ms

BC: 1661ms
CS: 1347ms

Order relations:
BC: 778ms
CS: 539ms

BC: 4621ms
CS: 3389ms

Functional operations:
BC: 442ms
CS: 435ms

BC: 2562ms
CS: 2159ms

Type transformations:
BC: 410ms
CS: 354ms

BC: 599ms
CS: 598ms

Algebraic operators:
BC: 600ms
CS: 494ms

BC: 8876ms
CS: 6740ms





On Tue, Feb 25, 2020 at 9:13 AM John Cowan  wrote:

> Perhaps separate OS processes would be a win in this case?
>
> On Tue, Feb 25, 2020 at 12:03 PM Matthew Butterick  wrote:
>
>>
>> > On Feb 25, 2020, at 7:05 AM, Matthew Flatt  wrote:
>> >
>> > * CS has a single heap with a single-threaded, stop-the-world GC ---
>> >   so allocation and GC easily become a bottleneck.
>> >
>> >   If GHC's experience is any guide, making the GC itself multithreaded
>> >   may address much of this problem.
>> >
>> > Locks on shared system data structures may also be a significant
>> > obstacle to CPU utilization with places in CS, but I'm not sure.
>>
>>
>>
>> FWIW some quick timings on a Pollen render of practicaltypography.com.
>> Though extra cores have diminishing net returns under Racket BC, the
>> returns are still positive. Under Racket CS, by contrast, net performance
>> degrades with more than 4 cores.
>>
>> Racket BC
>>
>> single core
>> real4m21.191s
>> user3m37.940s
>> sys 0m42.388s
>>
>> parallel @ 2 cores
>> real2m46.235s
>> user4m22.160s
>> sys 0m56.270s
>>
>> parallel @ 3 cores
>> real1m54.134s
>> user4m10.330s
>> sys 0m54.533s
>>
>> parallel @ 4 cores
>> real1m43.055s
>> user4m46.933s
>> sys 1m5.948s
>>
>> parallel @ 6 cores
>> real1m34.783s
>> user6m8.522s
>> sys 1m32.125s
>>
>> parallel @ 8 cores
>> real1m18.137s
>> user6m24.778s
>> sys 1m38.617s
>>
>> parallel @ 12 cores
>> real1m14.924s
>> user8m30.239s
>> sys 2m14.671s
>>
>> Racket CS
>>
>> single core
>> real5m1.422s
>> user4m16.300s
>> sys 0m44.253s
>>
>> parallel @ 2 cores
>> real3m25.016s
>> user4m45.385s
>> sys 0m54.634s
>>
>> parallel @ 3 cores
>> real2m52.780s
>> user4m57.951s
>> sys 1m3.184s
>>
>> parallel @ 4 cores
>> real2m42.471s
>> user5m22.796s
>> sys 1m17.889s
>>
>> parallel @ 6 cores
>> real2m44.513s
>> user6m26.700s
>> sys 1m54.549s
>>
>> parallel @ 8 cores
>> real2m56.782s
>> user8m4.029s
>> sys 2m58.554s
>>
>> parallel @ 12 cores
>> real3m2.116s
>> user9m34.846s
>> sys 5m5.443s
>>
>>
>>
>> --
>> 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/3D11BBCF-B0FE-473B-8997-09B7CB60D761%40mbtype.com
>> .
>>
> --
> 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/CAD2gp_S_kzyXFLCet_u8dHMCk_Wpgf-iS22Z7Az-oCNBXoEm5g%40mail.gmail.com
> 
> .
>

-- 
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/CACQBWF%3D0nTHabYLKD0hyGDPKBq%2B3N%3DkJPbXhm2f%2BjOWckdZtrA%40mail.gmail.com.


Re: [racket-users] Re: Organizing tests in project

2020-04-15 Thread Siddhartha Kasivajhula
I see, that explains it. Thank you for fixing it!


On Wed, Apr 15, 2020 at 12:58 PM Matthew Flatt  wrote:

> The machine that formerly ran pkg-build died, so pkg-builds stopped for
> a week or two. I moved eventually moved it to a new machine. Since I
> had to start over with a v7.6 installer and the current catalog, all
> packages were re-built and re-tested.
>
> At Wed, 15 Apr 2020 12:14:31 -0700, Siddhartha Kasivajhula wrote:
> > This morning I find that the package referenced above no longer
> > <https://pkgs.racket-lang.org/package/Relation> indicates failure. There
> > haven't been any new commits, so it appears that the package rebuilt on
> its
> > own without any fresh trigger -- but, notably, after a relatively long
> > (weeks long) interval. Does anyone know if this is normal? This section
> > <
> https://docs.racket-lang.org/pkg/getting-started.html#%28part._register-at-cat
> > alog%29>
> > of the docs appears to suggest that the docs are built daily.
> >
> >
> >
> > On Fri, Apr 10, 2020 at 11:07 AM Siddhartha Kasivajhula <
> skasi...@gmail.com>
> > wrote:
> >
> > > Hi, I'm still seeing an error
> > > <https://pkgs.racket-lang.org/package/Relation> on the Racket package
> > > server, but the build output is from March 31, 2019
> > > <https://pkg-build.racket-lang.org/server/built/test-fail/Relation.txt
> >
> > > and doesn't seem to be showing updated output. I gather that the server
> > > builds packages nightly -- any idea why it hasn't rebuilt yet? Or if it
> > > has, is there a way to get updated error output?
> > >
> > >
> > >
> > > On Mon, Apr 6, 2020 at 3:27 PM Siddhartha Kasivajhula <
> skasi...@gmail.com>
> > > wrote:
> > >
> > >> FTR I fixed this by using the `compile-omit-paths` flag:
> > >> https://docs.racket-lang.org/raco/setup-info.html
> > >> E.g. in info.rkt:
> > >>
> > >> (define compile-omit-paths '("tests"))
> > >>
> > >>
> > >>
> > >>
> > >> On Tue, Mar 17, 2020 at 12:25 PM Siddhartha Kasivajhula <
> > >> skasi...@gmail.com> wrote:
> > >>
> > >>> Hi,
> > >>> I'm attempting to organize tests in my package into
> subfolders/modules
> > >>> instead of having them in a giant main.rkt test submodule, but am
> running
> > >>> into some issues and was hoping for some advice on the best way to
> do it. I
> > >>> think the primary issue is related to source compilation order in
> raco, but
> > >>> am also curious how other people organize their tests.
> > >>>
> > >>> I've moved all of the tests into a tests/ subfolder in the main
> project
> > >>> tree. When I build the project using raco setup, it builds both the
> > >>> project files as well as the tests contained in the tests/ folder.
> At this
> > >>> point, if I run the tests as is, they result in an error. If instead
> I
> > >>> first delete the compiled/ subfolder in the tests folder, the tests
> then
> > >>> work fine.
> > >>>
> > >>> I think the tests may be getting compiled against the version of the
> > >>> compiled collection which is immediately replaced by a fresh
> compilation
> > >>> during raco setup. This is the error I'm seeing when I run the tests:
> > >>>
> > >>> default-load-handler: expected a `module' declaration, but found
> > >>> something else
> > >>>   file:
> > >>>
> >
> /Users/siddhartha/work/lisp/racket/relation/tests/compiled/algebraic-test_rkt.d
> > ep
> > >>>   context...:
> > >>>default-load-handler
> > >>>standard-module-name-resolver
> > >>>module-path-index-resolve
> > >>>module-declared?
> > >>>
> > >>> I could add a make target to clean the test compiled folder prior to
> > >>> running tests, but it seemed like there must be a better way. So my
> main
> > >>> questions are:
> > >>>
> > >>> 1. Is there a way to exclude certain folders (such as tests) in the
> raco
> > >>> setup stage? For reference, the command I'm using is raco setup
> > >>> --no-docs --tidy --pkgs relation.
> > >>> 2. Is this a good way to organize tests? Are there any standard
> > >>> recommend

[racket-users] Re: Organizing tests in project

2020-04-15 Thread Siddhartha Kasivajhula
This morning I find that the package referenced above no longer
<https://pkgs.racket-lang.org/package/Relation> indicates failure. There
haven't been any new commits, so it appears that the package rebuilt on its
own without any fresh trigger -- but, notably, after a relatively long
(weeks long) interval. Does anyone know if this is normal? This section
<https://docs.racket-lang.org/pkg/getting-started.html#%28part._register-at-catalog%29>
of the docs appears to suggest that the docs are built daily.



On Fri, Apr 10, 2020 at 11:07 AM Siddhartha Kasivajhula 
wrote:

> Hi, I'm still seeing an error
> <https://pkgs.racket-lang.org/package/Relation> on the Racket package
> server, but the build output is from March 31, 2019
> <https://pkg-build.racket-lang.org/server/built/test-fail/Relation.txt>
> and doesn't seem to be showing updated output. I gather that the server
> builds packages nightly -- any idea why it hasn't rebuilt yet? Or if it
> has, is there a way to get updated error output?
>
>
>
> On Mon, Apr 6, 2020 at 3:27 PM Siddhartha Kasivajhula 
> wrote:
>
>> FTR I fixed this by using the `compile-omit-paths` flag:
>> https://docs.racket-lang.org/raco/setup-info.html
>> E.g. in info.rkt:
>>
>> (define compile-omit-paths '("tests"))
>>
>>
>>
>>
>> On Tue, Mar 17, 2020 at 12:25 PM Siddhartha Kasivajhula <
>> skasi...@gmail.com> wrote:
>>
>>> Hi,
>>> I'm attempting to organize tests in my package into subfolders/modules
>>> instead of having them in a giant main.rkt test submodule, but am running
>>> into some issues and was hoping for some advice on the best way to do it. I
>>> think the primary issue is related to source compilation order in raco, but
>>> am also curious how other people organize their tests.
>>>
>>> I've moved all of the tests into a tests/ subfolder in the main project
>>> tree. When I build the project using raco setup, it builds both the
>>> project files as well as the tests contained in the tests/ folder. At this
>>> point, if I run the tests as is, they result in an error. If instead I
>>> first delete the compiled/ subfolder in the tests folder, the tests then
>>> work fine.
>>>
>>> I think the tests may be getting compiled against the version of the
>>> compiled collection which is immediately replaced by a fresh compilation
>>> during raco setup. This is the error I'm seeing when I run the tests:
>>>
>>> default-load-handler: expected a `module' declaration, but found
>>> something else
>>>   file:
>>> /Users/siddhartha/work/lisp/racket/relation/tests/compiled/algebraic-test_rkt.dep
>>>   context...:
>>>default-load-handler
>>>standard-module-name-resolver
>>>module-path-index-resolve
>>>module-declared?
>>>
>>> I could add a make target to clean the test compiled folder prior to
>>> running tests, but it seemed like there must be a better way. So my main
>>> questions are:
>>>
>>> 1. Is there a way to exclude certain folders (such as tests) in the raco
>>> setup stage? For reference, the command I'm using is raco setup
>>> --no-docs --tidy --pkgs relation.
>>> 2. Is this a good way to organize tests? Are there any standard
>>> recommended ways?
>>>
>>> Would appreciate any input,
>>> -Sid
>>>
>>>

-- 
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/CACQBWFmoQpDCcX5JThPKwfJ9cJDP9jYtWKBfyONG7sB37w7YOQ%40mail.gmail.com.


[racket-users] Re: Organizing tests in project

2020-04-10 Thread Siddhartha Kasivajhula
Hi, I'm still seeing an error
<https://pkgs.racket-lang.org/package/Relation> on the Racket package
server, but the build output is from March 31, 2019
<https://pkg-build.racket-lang.org/server/built/test-fail/Relation.txt> and
doesn't seem to be showing updated output. I gather that the server builds
packages nightly -- any idea why it hasn't rebuilt yet? Or if it has, is
there a way to get updated error output?



On Mon, Apr 6, 2020 at 3:27 PM Siddhartha Kasivajhula 
wrote:

> FTR I fixed this by using the `compile-omit-paths` flag:
> https://docs.racket-lang.org/raco/setup-info.html
> E.g. in info.rkt:
>
> (define compile-omit-paths '("tests"))
>
>
>
>
> On Tue, Mar 17, 2020 at 12:25 PM Siddhartha Kasivajhula <
> skasi...@gmail.com> wrote:
>
>> Hi,
>> I'm attempting to organize tests in my package into subfolders/modules
>> instead of having them in a giant main.rkt test submodule, but am running
>> into some issues and was hoping for some advice on the best way to do it. I
>> think the primary issue is related to source compilation order in raco, but
>> am also curious how other people organize their tests.
>>
>> I've moved all of the tests into a tests/ subfolder in the main project
>> tree. When I build the project using raco setup, it builds both the
>> project files as well as the tests contained in the tests/ folder. At this
>> point, if I run the tests as is, they result in an error. If instead I
>> first delete the compiled/ subfolder in the tests folder, the tests then
>> work fine.
>>
>> I think the tests may be getting compiled against the version of the
>> compiled collection which is immediately replaced by a fresh compilation
>> during raco setup. This is the error I'm seeing when I run the tests:
>>
>> default-load-handler: expected a `module' declaration, but found
>> something else
>>   file:
>> /Users/siddhartha/work/lisp/racket/relation/tests/compiled/algebraic-test_rkt.dep
>>   context...:
>>default-load-handler
>>standard-module-name-resolver
>>module-path-index-resolve
>>module-declared?
>>
>> I could add a make target to clean the test compiled folder prior to
>> running tests, but it seemed like there must be a better way. So my main
>> questions are:
>>
>> 1. Is there a way to exclude certain folders (such as tests) in the raco
>> setup stage? For reference, the command I'm using is raco setup
>> --no-docs --tidy --pkgs relation.
>> 2. Is this a good way to organize tests? Are there any standard
>> recommended ways?
>>
>> Would appreciate any input,
>> -Sid
>>
>>

-- 
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/CACQBWF%3DJDzWWhQSQPPx8Yu0v9zTYyQ%3DiGwJhH2r3kYqzEZuj9g%40mail.gmail.com.


[racket-users] Re: Organizing tests in project

2020-04-06 Thread Siddhartha Kasivajhula
FTR I fixed this by using the `compile-omit-paths` flag:
https://docs.racket-lang.org/raco/setup-info.html
E.g. in info.rkt:

(define compile-omit-paths '("tests"))




On Tue, Mar 17, 2020 at 12:25 PM Siddhartha Kasivajhula 
wrote:

> Hi,
> I'm attempting to organize tests in my package into subfolders/modules
> instead of having them in a giant main.rkt test submodule, but am running
> into some issues and was hoping for some advice on the best way to do it. I
> think the primary issue is related to source compilation order in raco, but
> am also curious how other people organize their tests.
>
> I've moved all of the tests into a tests/ subfolder in the main project
> tree. When I build the project using raco setup, it builds both the
> project files as well as the tests contained in the tests/ folder. At this
> point, if I run the tests as is, they result in an error. If instead I
> first delete the compiled/ subfolder in the tests folder, the tests then
> work fine.
>
> I think the tests may be getting compiled against the version of the
> compiled collection which is immediately replaced by a fresh compilation
> during raco setup. This is the error I'm seeing when I run the tests:
>
> default-load-handler: expected a `module' declaration, but found something
> else
>   file:
> /Users/siddhartha/work/lisp/racket/relation/tests/compiled/algebraic-test_rkt.dep
>   context...:
>default-load-handler
>standard-module-name-resolver
>module-path-index-resolve
>module-declared?
>
> I could add a make target to clean the test compiled folder prior to
> running tests, but it seemed like there must be a better way. So my main
> questions are:
>
> 1. Is there a way to exclude certain folders (such as tests) in the raco
> setup stage? For reference, the command I'm using is raco setup --no-docs
> --tidy --pkgs relation.
> 2. Is this a good way to organize tests? Are there any standard
> recommended ways?
>
> Would appreciate any input,
> -Sid
>
>

-- 
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/CACQBWF%3Dfk4bKNWgyT4sHz%3D-yOAw%3DdOtvJj0b8%3D%2BXNjDWTuDBJw%40mail.gmail.com.


Re: [racket-users] Re: Best way to handle different versions of Racket?

2020-04-04 Thread Siddhartha Kasivajhula
These sound like three different, alternative ways to do it! Nice to know
there are options which presumably each have their merits.

@Greg I'm using your Makefile template already
 :)


On Fri, Apr 3, 2020 at 6:54 AM Greg Hendershott 
wrote:

> Is there a standard/recommended way to handle multiple versions of Racket
>> in library code?
>>
>
> 1. You can use dynamic-require to see if the new thing is actually
> provided by a module, and in a with-handlers clause substitute your
> not-found, default behavior.
>
> If you do that frequently you could wrap that in a little macro like this:
>
>
> https://github.com/greghendershott/racket-mode/blob/master/racket/util.rkt#L86-L101
>
> 2. You could run tests using Travis CI or similar, against multiple/older
> versions of Racket.  For example:
>
>   https://github.com/greghendershott/racket-mode/blob/master/.travis.yml
>
>   https://github.com/greghendershott/travis-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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/1abd44b5-cec8-4c1a-a7d1-e2096f5a839d%40googlegroups.com
> 
> .
>

-- 
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/CACQBWFmu88RLrY06gLRrsm65fNi%2Bf7c9uW8H_OASoCtnq57e5Q%40mail.gmail.com.


Re: [racket-users] Best way to handle different versions of Racket?

2020-03-30 Thread Siddhartha Kasivajhula
Ah right, that makes sense :)


On Mon, Mar 30, 2020 at 12:29 PM Sorawee Porncharoenwase <
sorawee.pw...@gmail.com> wrote:

> The problem with shadowing is more than that. Suppose you somehow want to
> shadow add1 by making it add 2 instead.
>
> (define add1 (compose add1 add1))
>
> However, this will not work, resulting in the following error:
>
> add1: undefined;
>  cannot reference an identifier before its definition
>
> because blue add1 refers to red add1, not Racket’s add1.
>
> So you really need to either rename Racket’s add1 to something else, or
> define your add1 with another name. The first approach would be something
> like:
>
> (require (only-in racket [add1 @add1]))
> (define add1 (compose @add1 @add1))
>
> and the second approach would be something like:
>
> (define @add1 (compose add1 add1))
>
>
>
> On Mon, Mar 30, 2020 at 12:17 PM Siddhartha Kasivajhula <
> skasi...@gmail.com> wrote:
>
>> That looks great, thanks! Re: shadowing, I don't plan to re-provide
>> string-append-immutable -- only use it internally within the module, so
>> shadowing should be OK, right?
>> Re: reason to use it - performance. I'm applying the string-append
>> operation in a pairwise way over input sequences, and re-converting to
>> immutable at each step appears to have a measurable cost.
>>
>>
>> On Mon, Mar 30, 2020 at 12:11 PM Sorawee Porncharoenwase <
>> sorawee.pw...@gmail.com> wrote:
>>
>>> Is there any reason to use Racket’s string-append-immutable though? It
>>> might be simpler to just:
>>>
>>> (define string-append-immutable
>>>   (compose string->immutable-string string-append))
>>>
>>> (provide string-append-immutable)
>>>
>>> since you need to define it anyway for the versions prior 7.5.0.14.
>>>
>>> On Mon, Mar 30, 2020 at 12:00 PM Sorawee Porncharoenwase <
>>> sorawee.pw...@gmail.com> wrote:
>>>
>>>> Your code would not work because prior 7.5.0.14, there’s no
>>>> string-append-immutable, so the use of string-append-immutable in the
>>>> else branch will result in an unbound id error.
>>>>
>>>> Instead, use https://docs.racket-lang.org/version-case/index.html
>>>> which will run the “if” at compile-time, making the "unbound id" go away at
>>>> compile-time.
>>>>
>>>> Another problem is that when you define string-append (or even
>>>> string-append-immutable), it will shadow Racket’s string-append (or
>>>> string-append-immutable). You might want to do something like this
>>>> instead:
>>>>
>>>> (define @string-append-immutable ... now you can use 
>>>> string-append-immutable here ...)
>>>> (provide (rename-out [@string-append-immutable string-append-immutable]))
>>>>
>>>>
>>>>
>>>> On Mon, Mar 30, 2020 at 11:49 AM Siddhartha Kasivajhula <
>>>> skasi...@gmail.com> wrote:
>>>>
>>>>> Hi there,
>>>>> Is there a standard/recommended way to handle multiple versions of
>>>>> Racket in library code?
>>>>>
>>>>> For instance, this handy utility was added in a recent version of
>>>>> Racket:
>>>>>
>>>>>
>>>>> https://docs.racket-lang.org/reference/strings.html?q=strings#%28def._%28%28quote._~23~25kernel%29._string-append-immutable%29%29
>>>>>
>>>>> I'd like to use it in my library code but that would probably mean
>>>>> that users with an older version of Racket wouldn't be able to use the
>>>>> library, is that right? I'm tempted to add something like:
>>>>>
>>>>> (require version/utils)
>>>>> (define string-append
>>>>>   (if (version>>>>   (compose string->immutable-string string-append)
>>>>>   string-append-immutable))
>>>>>
>>>>> ... at the top of the module. Is this advisable? Or is there a better,
>>>>> maybe more raco-friendly way?
>>>>>
>>>>> Thanks,
>>>>> -Sid
>>>>>
>>>>>
>>>>> --
>>>>> 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/CACQBWFkRahhtoXKUbpcJ%2BHpYwq5FBU85Ze_NGkEntXX3kTD01g%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/racket-users/CACQBWFkRahhtoXKUbpcJ%2BHpYwq5FBU85Ze_NGkEntXX3kTD01g%40mail.gmail.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>>

-- 
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/CACQBWFmBpVWY%2B9bUo9uPk38n9f4tJvJg9HRKbv8LCkZ3gM%3D1qQ%40mail.gmail.com.


Re: [racket-users] Best way to handle different versions of Racket?

2020-03-30 Thread Siddhartha Kasivajhula
That looks great, thanks! Re: shadowing, I don't plan to re-provide
string-append-immutable -- only use it internally within the module, so
shadowing should be OK, right?
Re: reason to use it - performance. I'm applying the string-append
operation in a pairwise way over input sequences, and re-converting to
immutable at each step appears to have a measurable cost.


On Mon, Mar 30, 2020 at 12:11 PM Sorawee Porncharoenwase <
sorawee.pw...@gmail.com> wrote:

> Is there any reason to use Racket’s string-append-immutable though? It
> might be simpler to just:
>
> (define string-append-immutable
>   (compose string->immutable-string string-append))
>
> (provide string-append-immutable)
>
> since you need to define it anyway for the versions prior 7.5.0.14.
>
> On Mon, Mar 30, 2020 at 12:00 PM Sorawee Porncharoenwase <
> sorawee.pw...@gmail.com> wrote:
>
>> Your code would not work because prior 7.5.0.14, there’s no
>> string-append-immutable, so the use of string-append-immutable in the
>> else branch will result in an unbound id error.
>>
>> Instead, use https://docs.racket-lang.org/version-case/index.html which
>> will run the “if” at compile-time, making the "unbound id" go away at
>> compile-time.
>>
>> Another problem is that when you define string-append (or even
>> string-append-immutable), it will shadow Racket’s string-append (or
>> string-append-immutable). You might want to do something like this
>> instead:
>>
>> (define @string-append-immutable ... now you can use string-append-immutable 
>> here ...)
>> (provide (rename-out [@string-append-immutable string-append-immutable]))
>>
>>
>>
>> On Mon, Mar 30, 2020 at 11:49 AM Siddhartha Kasivajhula <
>> skasi...@gmail.com> wrote:
>>
>>> Hi there,
>>> Is there a standard/recommended way to handle multiple versions of
>>> Racket in library code?
>>>
>>> For instance, this handy utility was added in a recent version of Racket:
>>>
>>>
>>> https://docs.racket-lang.org/reference/strings.html?q=strings#%28def._%28%28quote._~23~25kernel%29._string-append-immutable%29%29
>>>
>>> I'd like to use it in my library code but that would probably mean that
>>> users with an older version of Racket wouldn't be able to use the library,
>>> is that right? I'm tempted to add something like:
>>>
>>> (require version/utils)
>>> (define string-append
>>>   (if (version>>   (compose string->immutable-string string-append)
>>>   string-append-immutable))
>>>
>>> ... at the top of the module. Is this advisable? Or is there a better,
>>> maybe more raco-friendly way?
>>>
>>> Thanks,
>>> -Sid
>>>
>>>
>>> --
>>> 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/CACQBWFkRahhtoXKUbpcJ%2BHpYwq5FBU85Ze_NGkEntXX3kTD01g%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/racket-users/CACQBWFkRahhtoXKUbpcJ%2BHpYwq5FBU85Ze_NGkEntXX3kTD01g%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/CACQBWFmoT_6rF4Z7poR%3DNVJ5GF2JTec3YCNqdduDi6pMfD%3D5nA%40mail.gmail.com.


[racket-users] Best way to handle different versions of Racket?

2020-03-30 Thread Siddhartha Kasivajhula
Hi there,
Is there a standard/recommended way to handle multiple versions of Racket
in library code?

For instance, this handy utility was added in a recent version of Racket:

https://docs.racket-lang.org/reference/strings.html?q=strings#%28def._%28%28quote._~23~25kernel%29._string-append-immutable%29%29

I'd like to use it in my library code but that would probably mean that
users with an older version of Racket wouldn't be able to use the library,
is that right? I'm tempted to add something like:

(require version/utils)
(define string-append
  (if (versionimmutable-string string-append)
  string-append-immutable))

... at the top of the module. Is this advisable? Or is there a better,
maybe more raco-friendly way?

Thanks,
-Sid

-- 
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/CACQBWFkRahhtoXKUbpcJ%2BHpYwq5FBU85Ze_NGkEntXX3kTD01g%40mail.gmail.com.


[racket-users] Organizing tests in project

2020-03-17 Thread Siddhartha Kasivajhula
Hi,
I'm attempting to organize tests in my package into subfolders/modules
instead of having them in a giant main.rkt test submodule, but am running
into some issues and was hoping for some advice on the best way to do it. I
think the primary issue is related to source compilation order in raco, but
am also curious how other people organize their tests.

I've moved all of the tests into a tests/ subfolder in the main project
tree. When I build the project using raco setup, it builds both the project
files as well as the tests contained in the tests/ folder. At this point,
if I run the tests as is, they result in an error. If instead I first
delete the compiled/ subfolder in the tests folder, the tests then work
fine.

I think the tests may be getting compiled against the version of the
compiled collection which is immediately replaced by a fresh compilation
during raco setup. This is the error I'm seeing when I run the tests:

default-load-handler: expected a `module' declaration, but found something
else
  file:
/Users/siddhartha/work/lisp/racket/relation/tests/compiled/algebraic-test_rkt.dep
  context...:
   default-load-handler
   standard-module-name-resolver
   module-path-index-resolve
   module-declared?

I could add a make target to clean the test compiled folder prior to
running tests, but it seemed like there must be a better way. So my main
questions are:

1. Is there a way to exclude certain folders (such as tests) in the raco
setup stage? For reference, the command I'm using is raco setup --no-docs
--tidy --pkgs relation.
2. Is this a good way to organize tests? Are there any standard recommended
ways?

Would appreciate any input,
-Sid

-- 
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/CACQBWF%3D5iwYRCOgwEmwNSh27QzpfE1pjFqvzzB_1KNs3zgHX5g%40mail.gmail.com.


[racket-users] New generic relations package

2019-12-06 Thread Siddhartha Kasivajhula
Hi folks,
Hope everyone's having a relaxing start to the holiday season. I've written
a package dealing with generic relations and types, just announcing it here
in case anyone finds it useful.

https://docs.racket-lang.org/relation/index.html

The package provides generic versions of order relations like < and =, and
algebraic operators like +, so that they work on any type that exhibits a
structure appropriate for the operation. I think of this as a complement to
something like data/collection, which when used together make the
experience of writing Racket type-agnostic for the most common cases. Here
are some examples:

> (< 1 2 3)

#t
> (< "apple" "banana" "cherry")

#t
> (= "apple" "APPLE")

#f
> (= #:key string-upcase "apple" "APPLE")

#t
> (.. "hi" " " "there")

"hi there"
> (+ #(1 2 3) #(1 2 3) #(1 2 3))

'#(3 6 9)
> (->list (stream 1 2 3))

'(1 2 3)
> (= #:key (.. even? ->number) "12" "20")

#t
> (min #:key length "apple" "pear" "strawberry")

"pear"

The #:key argument is worth noting as it allows you to provide a definition
of equivalence, i.e. supporting arbitrary equivalence classes on the input
type. This inclusion was inspired by a recent discussion on this list
(cc @George
Neuner  ). I also included the /= relation for good
measure :)

Performance wise I haven't really looked into optimizing it since it mostly
dispatches to built-in interfaces, but from profiling at an arm's length
using this package  just
to give an idea, it looks like the interfaces range about 1-4x slower than
built-in type-specific relations.

Some next steps or pipe dreams could be:
- supporting "ring" style distributive operators like the usual * for
generalized multiplication.
- looking into multi-dispatch, like what @Alexis talks about here
,
to make the implementation cleaner. This is probably a necessary
prerequisite to...
- ... adding more algebraic datatypes as templates for generic interfaces
(like the monoid or "composition-like" and group or "addition-like"
interfaces already present)
- ... which could be useful in supporting linear algebra types and
operations like the matrix operations in the math package

- more explicit treatment of order structures like lattices, supremums,
infimums in the order relations so that you could do something like (sup
) and it would return a result using a standard supremum-finding
algorithm across any types for which an order relation has been defined,
for example (sup canid felid) ; => carnivora

This is my first Racket package, so feedback of any kind would be much
appreciated. Thanks!

-Sid

-- 
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/CACQBWFmL4eBayQraWDuwYmhsK%2BGYvvajAF6gQBTPegguxMCQFA%40mail.gmail.com.


Re: [racket-users] Re: Reason why char=? accepts only one argument?

2019-11-26 Thread Siddhartha Kasivajhula
>
> What about Common Lisp's /= and char/= functions?  Can nonequivalent
> values form an equivalence class?


I don't think that would technically qualify as an equivalence class
because it would mean that an element is never equivalent to itself, which
is a definitional requirement for an equivalence class (reflexivity). In
fact the relation of "not equal" is not transitive either (another
requirement), since a /= b /= c does not prevent a = c. On the other hand,
because the relation is symmetric (a /= b implies b /= a), it does yield
"classes" that are subsets of the original set wherein every element is
"not equal" to every other, so that could be why they seem similar in some
way.

Can't comment on the decision to exclude /= since I'm not a member of the
development team :)

On Mon, Nov 25, 2019 at 8:15 AM George Neuner  wrote:

> On Mon, 25 Nov 2019 00:14:45 -0800, Siddhartha Kasivajhula
>  wrote:
>
> >Another way to think of it could be to interpret the operator as asking,
> >"do the arguments supplied form an equivalence class
> ><https://en.wikipedia.org/wiki/Equivalence_class>?" If only one argument
> is
> >supplied, then it trivially forms such a class.
>
> What about Common Lisp's /= and char/= functions?  Can nonequivalent
> values form an equivalence class?
>
> I note that neither Scheme nor Racket implements these functions.  Is
> there some pedagogical reason, or is it simply a practical realization
> that "(/= _)" is interchangeable with "(not (= _))" ?
>
>
> Not a language theorist, just an aging compiler geek.
> George
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/pfunteltm3sm5irkjifvh00r7mien6l1nm%404ax.com
> .
>

-- 
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/CACQBWFkiVS_BizS_885uSOSj2saKK_WDJZLswbgokHgP_HsSMQ%40mail.gmail.com.


Re: [racket-users] Reason why char=? accepts only one argument?

2019-11-25 Thread Siddhartha Kasivajhula
Another way to think of it could be to interpret the operator as asking,
"do the arguments supplied form an equivalence class
?" If only one argument is
supplied, then it trivially forms such a class.


On Sun, Nov 24, 2019 at 10:27 PM George Neuner  wrote:

>
>
> On 11/24/2019 5:30 PM, Jonathan Simpson wrote:
>
> The documentation for char=? leaves the impression that it takes a minimum
> of two arguments:
>
>
> https://docs.racket-lang.org/reference/characters.html?q=expand#%28def._%28%28quote._~23~25kernel%29._char~3d~3f%29%29
>
> If a single character is passed as argument 1, char=? returns true. To me,
> '=' implies at least two things to compare. The other functions in this
> family appear to behave the same way.
>
> There is a note saying that since 7.0 the functions accept one argument.
> Any reason for this change? At the very least I think the documentation
> could make this clearer(probably because the docs were originally written
> when it required two arguments).
>
> -- Jonathan
>
>
> I don't know the developers' reasoning, but I can guess.
>
> Predicates already were variadic taking 2 or more arguments (at least
> since R3RS, circa 1986), and they behave like a fold/reduce with an implied
> base/identity value.  I think the idea is that they should work with any
> non-empty list of arguments.
>
> FWIW, Common Lisp's predicates always have behaved in this way.
>
> YMMV,
> George
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/224f2bfe-1ee5-7a49-855f-19c21e202a83%40comcast.net
> 
> .
>

-- 
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/CACQBWFmPb26SQVrHhgg%3Djdvyc8u3-j8pFt2KkzGek6eXW_mbMA%40mail.gmail.com.


Re: [racket-users] Symex: a DSL for symbolic expressions

2019-08-01 Thread Siddhartha Kasivajhula
>
> > generalization of modal user interfaces that has a "language-oriented
> > programming" flavor.
> Applying traditionally-sexp structural-based editing to non-sexp
> languages seems relevant to non-sexp Racket2 syntax (e.g., Honu), and
> other non-sexp languages.


The generalization I'm referring to there is actually about Vim-style modal
interfaces -- a totally separate idea unrelated to language syntax. The
generalization you're talking about is intriguing as well, and I recently
learned about this library 
which could probably be leveraged to get language-agnostic structural
editing.

There was also some work on DrRacket (nee DrScheme):
> http://www.cs.brown.edu/research/plt/software/divascheme/


Divascheme looks great! The interface in symex.el is really similar to it,
as a matter of fact (which may be because they are both similar to Vim...).
If there are any features here that you miss and would like to see in
Emacs, I'm happy to look into adding it to symex since it seems like they
have a similar conceptual approach.

In addition to deriving structural editing from language descriptions,
> there's also opportunity for DSL/macros/learning additional
> language-sensitive structural transformations (I couldn't see whether
> symex.el tackles these).


Not at the moment. Symex operates at the syntactic level of the code and
not the semantic level, so only syntactic transformations are possible for
now. Xah Lee (a prolific and occasionally iconoclastic Emacs blogger) also
talks about some semantic-level transformations here
 -- it would be
great to have such functionality at some point, and again, maybe
tree-sitter or LSP  can help with this.




On Thu, Aug 1, 2019 at 3:37 AM Hendrik Boom  wrote:

> On Wed, Jul 31, 2019 at 06:40:05PM -0400, Neil Van Dyke wrote:
> >
> > For structured editing related work in sexp, of course there's Emacs
> > structural operations that have been in there forever (not well-known,
>
> Certainly not well known.
> I've been using emacs for decades, and I never heard of them.
> What are they?  Do you have a ilnk to their documentation?
>
> -- hendrik
>
> --
> 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/20190801103655.3cwjoqc3ahdqj4ci%40topoi.pooq.com
> .
>

-- 
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/CACQBWF%3DkwvQ2Mqeq%2B9k9t3mf9ZUKk-oshoCS%3DgaeTZYiq3A5GQ%40mail.gmail.com.


[racket-users] Symex: a DSL for symbolic expressions

2019-07-29 Thread Siddhartha Kasivajhula
Hi folks,
I've been lurking in these here forums for a little while now. Over the
years I've looked for the perfect language to implement toy projects in and
nothing seemed quite right. It wasn't until I found Racket a few months ago
that I felt I'd finally come home. Racket seems like an innovative, robust,
and inclusive community and I'm excited to see where things go, esp. with
the recent announcements.

Anyhow, that overdue introduction aside, I've written a DSL for editing
symbolic expressions, not in Racket but in Emacs Lisp, to support a
Vim-style editing interface for Emacs. If you're an Emacs user and
intrigued by modal interfaces, take a look:

https://github.com/countvajhula/symex.el

There's also a video overview and demo here:

https://www.youtube.com/watch?v=a5s1ScTx8Zk

... which features an example in Racket at around 12:05.

Towards the end of the presentation (around 50:07) I talk about a
generalization of modal user interfaces that has a "language-oriented
programming" flavor.

Enjoy,
-Sid

-- 
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/CACQBWFkUnN30qNzmMCW_15zqKyF%3DaWmf0npOU3BHZ4UuhjO%2BBQ%40mail.gmail.com.


Re: [racket-users] Haskell

2019-05-16 Thread Siddhartha Kasivajhula
This may be of interest:
https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours

Though, as others have said, this sounds like a more typical usecase for
racket.


On Tue, May 14, 2019 at 8:23 AM Josh Rubin  wrote:

> It just occurred to me that Haskell could be a powerful way to manipulate
> programs in other languages (like Scheme or Racket). Unfortunately, I don't
> know Haskell. Has anybody been down this path?
>
> --
> Josh rubinjlru...@gmail.com
>
>  --
> 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/d2961559-f8af-c6d0-15e1-9c20b3dab959%40gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CACQBWFmzjq6tYc-W0WaY5VgP73uTSzqbS6DZ82Uk9kXjOTq1og%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] Unexpected behavior with (in-set)?

2019-05-04 Thread Siddhartha Kasivajhula
Hi there,
I was surprised by this behavior, but it's entirely possible there's a good
reason for it. Bringing it up to understand what that might be. In using
(in-set) or (in-mutable-set) in a for loop, it seems that if the loop is
removing and adding elements to the set it is iterating over, the sequence
might terminate even if the set is non-empty.

Example:
(let ([my-set (mutable-set 0)])
  (for ([i (in-mutable-set my-set)])
(printf "~a\n" i)
(when (= i 0)
  (set-remove! my-set i)
  (set-add! my-set 1

Outputs:
>
0

Instead of the expected:
>
0
1

Changing the code to remove the (set-remove! my-set i) line:

(let ([my-set (mutable-set 0)])
  (for ([i (in-mutable-set my-set)])
(printf "~a\n" i)
(when (= i 0)
  (set-add! my-set 1

...  produces the expected output.

On a related note, I'm not exactly clear on what a sequence is that isn't a
stream or a list or some other concrete type. Sequences appear to be an
abstract type, and yet (in-set) is an instance of it (unlike e.g. (in-list)
which is a stream..) so it must not be abstract. Perhaps this is the key to
my confusion here?

Thanks,
-Sid

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