[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
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
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 McGrathwrote: > 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
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 Firthwrote: > 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
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
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
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
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 Georgeswrote: > 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
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
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 Liebgoldwrote: > 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
> On Jan 30, 2017, at 11:42 AM, Leif Andersenwrote: > > 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
> 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
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
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 Estradawrote: > 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
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
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
On Mon, Jan 30, 2017 at 1:12 PM, Greg Trzeciakwrote: > 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
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.