[racket-users] Re: Racket PPA updated for 6.8

[张可星]

在 2017年1月31日星期二 UTC+8上午12:37:14，asumu写道：
> Hi all,
> 
> The Racket PPA for Ubuntu has been updated to v6.8:
> 
>   https://launchpad.net/~plt/+archive/ubuntu/racket 
> 
> I'm not sure why, but v6.8 didn't build correctly for precise and trusty so 
> for
> now the PPA just supports xenial, yakkety, and zesty.
> 
> Also you may notice the icon for the DrRacket launcher is still the old one. I
> plan on releasing a minor update for the packaging later that uses the new 
> icon
> and fixes some minor dependency bugs.
> 
> Cheers,
> Asumu

There is a white circle on the icon . It looks a little ugly.

-- 
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] Racket PPA updated for 6.8

[Asumu Takikawa]

On 2017-01-30 11:36:41 -0500, Asumu Takikawa wrote:
> I'm not sure why, but v6.8 didn't build correctly for precise and trusty so 
> for
> now the PPA just supports xenial, yakkety, and zesty.

Update: the precise and trusty builds for v6.8 should now work. (thanks to
Andrew Kent for the fix)

I also updated the DrRacket launcher icon. The package version should be bumped
on all supported releases now.

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] Re: Package layout in docs

[WarGrey Gyoudmon Ju]

Hello.

This is one of the culture shocks that a new Racketeer would face, and so
was I.
But this statement makes it clear to me: Racket is an operating system that
pretend to a programming language;

Yes, it may totally be a kind of over reading here.

Say, I do not care if a manual page is the one shipped with unix
distribution or installed by user, same to shell commands and shared
objects, all entries should globally unique.

Okay, the documentation system is a little different here, it can be
provided with a different front page, and obviously there is no way to
satisfy all.
Actually I am afraid of where to insert the entry of my package as well.

Of my preference, I would suggest putting status icons (or even emojis) in
front of every entry in the index page based on the ring system.


On Tue, Jan 31, 2017 at 11:57 AM, Philip McGrath 
wrote:

> I was also going to suggest the ring system as a way of giving more
> information without imposing an unnecessary artificial distinction. In
> general I'm enthusiastic about the benefits of not having a sharp dividing
> line, but it would be useful to show more clearly in the documentation
> which packages have been vetted to "ring zero" standards.
>
>
>
>
> On Mon, Jan 30, 2017 at 8:46 PM, Jack Firth  wrote:
>
>> Rather than splitting "core packages" from "community packages", what if
>> we used the package ring system? [1] We could establish a way for the
>> Racket community to bless packages with "ring zero" status, then provide a
>> --catalog argument to Scribble to lookup ring information in when deciding
>> how to style package documentation. The docs would remain unified, we'd
>> have a centralized place to curate packages, and there's no artificial
>> barrier that prevents user-contributed packages from living alongside
>> main-distribution packages.
>>
>> [1] http://docs.racket-lang.org/pkg/Future_Plans.html?q=ring
>>
>> --
>> 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.

Re: [racket-users] Re: Package layout in docs

[Philip McGrath]

I was also going to suggest the ring system as a way of giving more
information without imposing an unnecessary artificial distinction. In
general I'm enthusiastic about the benefits of not having a sharp dividing
line, but it would be useful to show more clearly in the documentation
which packages have been vetted to "ring zero" standards.



On Mon, Jan 30, 2017 at 8:46 PM, Jack Firth  wrote:

> Rather than splitting "core packages" from "community packages", what if
> we used the package ring system? [1] We could establish a way for the
> Racket community to bless packages with "ring zero" status, then provide a
> --catalog argument to Scribble to lookup ring information in when deciding
> how to style package documentation. The docs would remain unified, we'd
> have a centralized place to curate packages, and there's no artificial
> barrier that prevents user-contributed packages from living alongside
> main-distribution packages.
>
> [1] http://docs.racket-lang.org/pkg/Future_Plans.html?q=ring
>
> --
> 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] Re: Package layout in docs

[Jack Firth]

Rather than splitting "core packages" from "community packages", what if we 
used the package ring system? [1] We could establish a way for the Racket 
community to bless packages with "ring zero" status, then provide a --catalog 
argument to Scribble to lookup ring information in when deciding how to style 
package documentation. The docs would remain unified, we'd have a centralized 
place to curate packages, and there's no artificial barrier that prevents 
user-contributed packages from living alongside main-distribution packages.

[1] http://docs.racket-lang.org/pkg/Future_Plans.html?q=ring

-- 
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] Package layout in docs

[Laurent]

I agree that in the TOC of the docs it would probably be better to separate
third party packages, maybe simply as a dedicated section or add
'(contributed package)' next to it.

On 30 Jan 2017 9:13 pm, "Matthew Butterick"  wrote:


On Jan 30, 2017, at 11:42 AM, Leif Andersen  wrote:

I don't think that the solution is to make core packages first class, and
community ones second class. That looses the spirit of what we're going for
here. But maybe we could have in our documentation a way for users to
select what packages they want to show up in search results. That way all
packages are equal here, and a person who wants to, say, only use core
packages, can get that.


To be fair, not all core packages are superior to their community variants.

For instance, `parser-tools` is core, yet has been called "strange and
klunky" compared to "modern Racket". [1] Whereas the `ragg` package is a
much nicer — dare I say more Rackety — interface to `parser-tools`.

So if Racket's policy is to let the boundary between core & community
remain porous, then it seems consistent to let these packages compete on an
even footing.


An alternative approach which probably takes less effort is to just have
two documentation pages. One for core packages, and one for community
packages. Obviously we should still make 3rd party packages feel like first
class build in stuff, but if we just host them at a different URL, that
might be enough to keep things clear.


Recently we added a Racket logo to the upper right of the public doc pages.
We could do something where this logo changed depending on whether the
package belonged to core or community or whatever. Then we wouldn't need to
actually cleave the docs into two websites (which IMO is
counterproductive).

Later we can get to Yelp-style star reviews: "Meh, I've experienced better
mutable vectors."



[1] https://groups.google.com/d/msg/racket-dev/pVcE3hdsfbM/U8dBBcPfCAAJ

-- 
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] Package layout in docs

[Ethan Estrada]

Putting the logo in the corner or line under the title solves only half of
the problem, IMHO. Yes, you can determine which packages are core and which
are community, however you still can't differentiate at a glance which is
which. Although it is an improvement, it is still a pain in practice since
one needs to check each link to see the provenance of a package/library.
Where there are clearly a few different packages for a given thing, this
can cost time and aggravation. For instance, there are two or three
packages for parsing html, two for json, two or three for OpenGL and so
forth. Which is a core library? Which is a toy that someone made to explore
that particular domain and try out the package system? Which is a
production tool that someone built to solve an actual problem they were
facing?

Another possible way might be to have each item have effectively a bullet
point on the main page, but the bullet point is an icon; the stylized
Racket Lambda icon for core packages and a different one for community
supplied ones. For instance, a stylized group of people like here:

https://duckduckgo.com/?q=community+icon=1=images

The fact that community generated packages are on the front docs page still
gives them equal status, even while clearly indicating their origin.

To address Matthew's point of some community packages being more idiomatic
or easier to work with than some core racket libraries, I don't think
obfuscating their origin necessarily helps users discover alternative
packages more easily. Most often, users (in any software ecosystem) will
learn that one package is easier/better/faster/friendlier by asking around
on mailing lists, chat groups or user forums. If people don't ask in those
places, then it essentially becomes a coin toss. "Which package do I try
out first?" Then they will either stick with the first one they try because
it is good enough, or they will go to the next one because the first one
wasn't good enough. With differentiating the packages, it takes out the
coin toss which takes time and energy. Yes, I may end up using a community
provided package because the core package isn't quite up to snuff for my
needs, but at least I didn't need to wonder which one I should try first.
As it is, a new user is flying somewhat blind.

Also, +1 what Lehi said; more than once I have tried to `(require)`
something, thinking it was part of the standard install and then been
barked at because I need to go out and fetch the package first.

--
Ethan Estrada | CTO & COO
M: 801-669-1598 | E: et...@metapipe.com
The Startup Building | 560 S 100 W STE 1, Provo UT 84601-4570
MetaPipe.com


Making the Cloud easy to use for VFX and Animation

On Mon, Jan 30, 2017 at 3:02 PM, Dupéron Georges <
jahvascriptman...@gmail.com> wrote:

> Le lundi 30 janvier 2017 22:13:57 UTC+1, Matthew Butterick a écrit :
> > Recently we added a Racket logo to the upper right of the public doc
> pages. We could do something where this logo changed depending on whether
> the package belonged to core or community or whatever. Then we wouldn't
> need to actually cleave the docs into two websites (which IMO is
> counterproductive).
>
> I agree with Matthew Butterick that splitting the docs into two websites
> would be counterproductive. As a user, I don't want to have to remember
> whether this package happens to be in main-distribution or not, and look up
> one website or the other. The same applies when searching for a
> functionality: I would rather avoid having to search on two different
> websites.
>
> The logo idea seems like a nice compromise.
>
> Another possibility would be to change the packages so that they display
> somewhere below the title "Part of the community package foo", "Part of the
> main Racket distribution" or "Part of the minimal Racket distribution". As
> far as I can tell, this would require cooperation from the packages
> (modifying the scribble files), unless Scribble forcefully inserts the text
> (like the "v.6.8" above the title).
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Racket Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/racket-users/bDkB2H8VO_I/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Package layout in docs

[Leif Andersen]

So, I really don't care how it work. Logo is fine, seperate website is
fine. Checkboxes that lets users say what packages come in are fine.
Yelp reviews are fine (although if we go down that route can we also
add Edit buttons. ;) )

My only concern is that at the moment, anyone can publish something
that very much looks and feels like it was either done by, or
supported by, PLT Design Inc. Which is a potentially dangerous thing.
All of the above solutions y'all suggested solve that issue. ;)

(Oh also Matthew, I completely agree with you. There are some pretty
awesome community built packages which I like way more than the one in
the core distribution.)

~Leif Andersen


On Mon, Jan 30, 2017 at 5:02 PM, Dupéron Georges
 wrote:
> Le lundi 30 janvier 2017 22:13:57 UTC+1, Matthew Butterick a écrit :
>> Recently we added a Racket logo to the upper right of the public doc pages. 
>> We could do something where this logo changed depending on whether the 
>> package belonged to core or community or whatever. Then we wouldn't need to 
>> actually cleave the docs into two websites (which IMO is counterproductive).
>
> I agree with Matthew Butterick that splitting the docs into two websites 
> would be counterproductive. As a user, I don't want to have to remember 
> whether this package happens to be in main-distribution or not, and look up 
> one website or the other. The same applies when searching for a 
> functionality: I would rather avoid having to search on two different 
> websites.
>
> The logo idea seems like a nice compromise.
>
> Another possibility would be to change the packages so that they display 
> somewhere below the title "Part of the community package foo", "Part of the 
> main Racket distribution" or "Part of the minimal Racket distribution". As 
> far as I can tell, this would require cooperation from the packages 
> (modifying the scribble files), unless Scribble forcefully inserts the text 
> (like the "v.6.8" above the title).

-- 
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] Package layout in docs

[Dupéron Georges]

Le lundi 30 janvier 2017 22:13:57 UTC+1, Matthew Butterick a écrit :
> Recently we added a Racket logo to the upper right of the public doc pages. 
> We could do something where this logo changed depending on whether the 
> package belonged to core or community or whatever. Then we wouldn't need to 
> actually cleave the docs into two websites (which IMO is counterproductive). 

I agree with Matthew Butterick that splitting the docs into two websites would 
be counterproductive. As a user, I don't want to have to remember whether this 
package happens to be in main-distribution or not, and look up one website or 
the other. The same applies when searching for a functionality: I would rather 
avoid having to search on two different websites.

The logo idea seems like a nice compromise.

Another possibility would be to change the packages so that they display 
somewhere below the title "Part of the community package foo", "Part of the 
main Racket distribution" or "Part of the minimal Racket distribution". As far 
as I can tell, this would require cooperation from the packages (modifying the 
scribble files), unless Scribble forcefully inserts the text (like the "v.6.8" 
above the title).

-- 
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] DrRacket debugger

[Robby Findler]

It isn't an issue I know about.

I don't see that with this simple program:

#lang racket
(let loop () (loop))

Do you?

Robby


On Mon, Jan 30, 2017 at 2:12 PM, Dan Liebgold
 wrote:
> I'm having trouble with the debugger in DrRacket: I'll start it and the 
> debugger buttons available at the top will stay "Go" and "Step" even as my 
> program is clearly running (even stuck in a loop).
>
> Is this a known issue?
>
> --
> 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] Package layout in docs

[Matthew Butterick]

> On Jan 30, 2017, at 11:42 AM, Leif Andersen  wrote:
> 
> I don't think that the solution is to make core packages first class, and 
> community ones second class. That looses the spirit of what we're going for 
> here. But maybe we could have in our documentation a way for users to select 
> what packages they want to show up in search results. That way all packages 
> are equal here, and a person who wants to, say, only use core packages, can 
> get that.

To be fair, not all core packages are superior to their community variants. 

For instance, `parser-tools` is core, yet has been called "strange and klunky" 
compared to "modern Racket". [1] Whereas the `ragg` package is a much nicer — 
dare I say more Rackety — interface to `parser-tools`. 

So if Racket's policy is to let the boundary between core & community remain 
porous, then it seems consistent to let these packages compete on an even 
footing.


> An alternative approach which probably takes less effort is to just have two 
> documentation pages. One for core packages, and one for community packages. 
> Obviously we should still make 3rd party packages feel like first class build 
> in stuff, but if we just host them at a different URL, that might be enough 
> to keep things clear.

Recently we added a Racket logo to the upper right of the public doc pages. We 
could do something where this logo changed depending on whether the package 
belonged to core or community or whatever. Then we wouldn't need to actually 
cleave the docs into two websites (which IMO is counterproductive). 

Later we can get to Yelp-style star reviews: "Meh, I've experienced better 
mutable vectors."



[1] https://groups.google.com/d/msg/racket-dev/pVcE3hdsfbM/U8dBBcPfCAAJ

-- 
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] Package layout in docs

[Lehi Toskin]

> An alternative approach which probably takes less effort is to just have two 
> documentation pages. One for core packages, and one for community packages. 
> Obviously we should still make 3rd party packages feel like first class build 
> in stuff, but if we just host them at a different URL, that might be enough 
> to keep things clear.

+1 - I really like that the documentation generated for any given package looks 
the same as another, but there have been some times where I've searched through 
the documentation and found a package where it was not obvious it was 
user-submitted and got confused when Racket complained that package wasn't 
installed already.

-- 
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] DrRacket debugger

[Dan Liebgold]

I'm having trouble with the debugger in DrRacket: I'll start it and the 
debugger buttons available at the top will stay "Go" and "Step" even as my 
program is clearly running (even stuck in a loop).

Is this a known issue?

-- 
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] Package layout in docs

[Leif Andersen]

FWIW, I have to support Ethan here. (At least a little bit).

I really how user installed packages (and collections) in Racket feel like
first class citizens. Its very nice, both that its rewarding when I make a
new package, but also in terms of searching for documentation and whatnot.

However, there is something to be said about having them show up as results
on the _official docs_ on our webpage.

Anyone can upload a package to pkgs.racket-lang.org and, provided that it
compiles, we'll display the content on our webpage as if it was a first
class thing.

While we have a sandbox to prevent certain classes of technical malicious
attacks we don't really have much in place (other than the community) for
social engineering based attacks.

For example, I could make a package that looks normal, acts normal, and
most of the docs are normal, but in the docs it links to some malicious
page, or has misleading content. Well, now we just not only gave this
package a platform, but we gave it a platform that looks like we 100%
endorse it, because its mixed seamlessly in with the API that ships with
the core distribution.

I don't think that the solution is to make core packages first class, and
community ones second class. That looses the spirit of what we're going for
here. But maybe we could have in our documentation a way for users to
select what packages they want to show up in search results. That way all
packages are equal here, and a person who wants to, say, only use core
packages, can get that.

An alternative approach which probably takes less effort is to just have
two documentation pages. One for core packages, and one for community
packages. Obviously we should still make 3rd party packages feel like first
class build in stuff, but if we just host them at a different URL, that
might be enough to keep things clear.

just some thoughts anyway.


~Leif Andersen

On Sun, Jan 29, 2017 at 3:48 PM, Ethan Estrada 
wrote:

> Curse my sausage fingers! That last send was unintentional. I've deleted
> it from the online Google Groups forum for the sake of future subscribers.
>
> I can understand wanting to minimize the distinction and in some ways make
> all core language, standard libraries, and community libraries equal.
>
> For me the issue is software maintenance. If I'm building something that
> needs functionality from an external library, I'm more likely to choose a
> library from the standard install if one exists. I can be reasonably
> certain it will be supported for a long time into the future, and if it
> ever ceases to be supported it will likely be gracefully deprecated over
> the course of a few releases. Neither of those points are guaranteed, but I
> think they are reasonable assumptions to make.
>
> Also, to some extent there already is a distinction in the documentation.
> There is the section "Racket Language and Core Libraries", and then there
> is everything else. However, the libraries from the 'base' package and
> other shipped packages are sprinkled into the "everything else" docs and
> not all the shipped packages are listed under "Racket Language and Core
> Libraries". So it makes things murky.
>
> A possible compromise may be to have the top level page of http://
> docs.racket-lang.org/ remain the same, but have a small link/page under
> http://docs.racket-lang.org/reference/ page that lists the links to all
> the packages/libraries/collections that are shipped by default with Racket.
> The pages that the links point to would all still live where they always
> have and still be listed at the top level http://docs.racket-lang.org/
> the same way they already are. That way there is some centralized place to
> figure out what ships with racket without mucking around the filesystem
> after install, or checking on each link on http://docs.racket-lang.org/
> to see if the package it requires from is 'base' or something else core to
> the install.
>
> To Stephen, thanks for sharing the articles from Eric Raymond. It made me
> think maybe I'm not just a crazy guy on the street corner wearing a burlap
> sack and a tin foil hat declaring the end of the world. Or, at the very
> least, I'm not alone on the street corner :) .
>
> --
> Ethan Estrada
>
> On Jan 29, 2017 06:45, "Matthew Flatt"  wrote:
>
> At Sat, 28 Jan 2017 22:51:43 -0800 (PST), Ethan Estrada wrote:
> > My only real beef with the Racket docs are the layout of packages;
> > there is no clear distinction between docs for standard library items
> > and docs for community provided libs.
>
> That's intentional. I'd say that the absence of a line that
> distinguishes "Racket" from "not Racket" at the package level is an
> extrapolation of our goal to avoid a line between the "language" and
> "library" at the level of a module.
>
> There are certainly some drawbacks to allowing any old module to add
> new constructs to the programming language, but we think the benefits
> outweigh the drawbacks. 

Re: [racket-users] link: bad variable linkage

[jon stenerson]

Sorry I missed this. Apparently I'm several months behind on the racket 
list.  The problem does seem fixed however. Thank you!


Jon


On 10/23/2016 11:34 AM, Laurent wrote:
As of now, I haven't experienced any more problem of this sort since 
then. Admittedly I haven't tried hard either to reproduce this behavior.


So thank you so much for the time you took to look into this! Very 
appreciated.



On Sat, Mar 26, 2016 at 11:53 PM, Robby Findler 
> wrote:


Matthew and I have figured out one way in which DrRacket could go
wrong here and implemented a better strategy. The problem we
identified doesn't explain the symptoms expressed here in this thread
exactly, but it is a complex system and maybe there was some piece
missing from the explanations that I didn't think to ask about.
Finger's crossed that it helps!

In any case, if you are still experiencing the bad symptom after you
get the latest code, please let me know.

Thanks,
Robby

On Mon, Feb 1, 2016 at 9:03 AM, Laurent > wrote:
> I would be so happy if this kind of error could be resolved!
(even when all
> files are compiled by DrRacket)
> Usually, I just turn off "populate 'compiled' directories", but then
> DrRacket needs to compile the file on each F5, which can take
some precious
> time.
> Thank you both then :)
>
> On Sun, Jan 31, 2016 at 11:19 PM, jon stenerson
>
> wrote:
>>
>>
>> The simplest thing I can find: I have three files in two
directories.
>> The first directory, called junk, contains a.rkt and b.rkt.
>> The second directory is a sibling to junk called local-libs and
contains
>> c.rkt. (local-libs is known to the package manager; it was
installed via the
>> DrRacket interface).
>> If I open all three files in DrRacket and try running a.rkt,
sometimes it
>> works, sometimes not. By modifiying a, b, c in some order (in
the DrRacket
>> editor) I can toggle the work/not work flag. As you say, it's a
little
>> non-deterministic.
>>
>> Thanks,
>> Jon
>>
>>
>> a.rkt:
>> #lang racket
>> (require "b.rkt")
>>
>> b.rkt
>> #lang racket
>> (require "../local-libs/c.rkt")
>> (s 1)
>>
>> c.rkt
>> #lang racket
>> (provide (struct-out s) )
>> (struct s (p))
>>
>>
>>
>>
>> On 1/31/2016 4:03 PM, Robby Findler wrote:
>>>
>>> Then it would be helpful to us if you could provide some
(hopefully
>>> small) program and instructions to reproduce the problem.
>>>
>>> Thanks,
>>> Robby
>>>
>>>
>>> On Sun, Jan 31, 2016 at 4:51 PM, jon stenerson
>
>>> wrote:

 Just using DrRacket 6.3 on Win 10.

 Jon


 On 1/31/2016 3:22 PM, Robby Findler wrote:
>
> The compilation of racket is (not yet) deterministic so
things like
> that can throw off internal tables in the .zo files (and a
.zo files
> is loaded without checking dependencies, optimistically
hoping that
> the files are not changed).
>
> So: are you using "raco make" or somehow mangaging .zo files
yourself,
> or are you seeing this with the .zo files that DrRacket
maintains for
> your automatically? If the former, then you need to adapt your
> workflow to either not use .zo files or to keep them up to
date. If
> the latter, then it is a bug.
>
> Robby
>
>
>
> On Sun, Jan 31, 2016 at 4:17 PM, jon stenerson
> >
> wrote:
>>
>> I have some .rkt files and, depending on which file was
edited most
>> recently, either it works fine or it gives a compilation
error. (By
>> "edited"
>> I mean just adding or subtracting a blank line to change the
>> timestamp).
>> I
>> can submit a simplified example if nobody else has seen
this problem.
>> If
>> this is well-known, what is the fix?
>>
>> link: bad variable linkage;
>>reference to a variable that is not a procedure or
structure-type
>> constant
>> across all instantiations
>> reference phase level: 0
>> variable module: 
>> variable phase: 0
>> reference in module:  in: 
>>
>> --
>> You received this message because you are subscribed to the
Google
>> Groups
>> "Racket Users" group.
>> To unsubscribe from this group 

Re: [racket-users] Arrays performance in untyped Racket

[Greg Trzeciak]

On Monday, January 30, 2017 at 2:20:36 PM UTC+1, Sam Tobin-Hochstadt wrote:
> We have reduced this overhead somewhat, but it's still likely to be
> prohibitive in many cases.
> 
> I think that "We are working on it" may need to be interpreted on an
> academic time scale in this case.
> 
> Sam

Ok, thank you for the update and realistic assessment. Nevertheless add my vote 
to the people expressing interest in it.

-- 
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] Arrays performance in untyped Racket

[Sam Tobin-Hochstadt]

On Mon, Jan 30, 2017 at 1:12 PM, Greg Trzeciak  wrote:
> I need to use Arrays/Matrix from untyped Racket but then I noticed the 
> following in the docs (https://docs.racket-lang.org/math/array.html):
>
> "Performance Warning: Indexing the elements of arrays created in untyped 
> Racket is currently 25-50 times slower than doing the same in Typed Racket, 
> due to the overhead of checking higher-order contracts. We are working on it."
>
> Has there been any progress in this area and what are the chances that the 
> overhead may fall to more reasonable in this area in the near future?

We have reduced this overhead somewhat, but it's still likely to be
prohibitive in many cases.

I think that "We are working on it" may need to be interpreted on an
academic time scale in this case.

Sam

-- 
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] Arrays performance in untyped Racket

[Greg Trzeciak]

I need to use Arrays/Matrix from untyped Racket but then I noticed the 
following in the docs (https://docs.racket-lang.org/math/array.html):

"Performance Warning: Indexing the elements of arrays created in untyped Racket 
is currently 25-50 times slower than doing the same in Typed Racket, due to the 
overhead of checking higher-order contracts. We are working on it."

Has there been any progress in this area and what are the chances that the 
overhead may fall to more reasonable in this area in the near future?

Thank you
Greg



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