Re: [racket-users] Real-world examples of XML usage?

[Neil Van Dyke]

David Storrs wrote on 2/2/19 11:57 PM:

Are there angles here that I haven't encountered or thought about yet?


As a fellow Racketeer with mixed feelings about XML, let me articulate 
for the list an angle you might've already considered...


One reason you might decide to use XML for a system interface (when not 
required to, nor encouraged by it possibly helping sales to some 
customers) is that you want to help the programmers on the other side of 
the interface to be correct, for very selfish reasons.


(We must remind ourselves not to underestimate the capacity for 
incorrectness in software systems development.  We know it's bad, but 
it's worse than that.)


If everyone's messages have to validate to a particular DTD/schema, that 
lets you throw in what's effectively a bunch of checking they can do 
themselves, on their side, gives them blame-pointing error messages, and 
eliminates some of the phases of incorrectness on their end.


Incorrectness phases avoided is less work for you (consider if they're 
talking to a service you're selling them, and/or contacting you for 
support when their code is broken, or their floundering becomes an 
enterprise-scale diplomatic problem for you), and less of you waiting on 
them (for, e.g., integration, or a sale),  and presumably makes them 
happier, as well.


There are numerous other ways in software you could accomplish the same 
goals--  *but* XML is a popular open standard, so a lot of mutual 
understanding and agreement is accomplished instantly.


It's possible to not love everything about XML, yet to see that it has 
technical merits, and to see very practical value in a popular open 
standard interface.  The practical value includes that a standard at the 
interface lets you use tools you like more on your side of the 
interface.  This standard gives you the flexibility to innovate with 
Racket+XML, rather than everyone in that sector forced for a decade to 
all use IckyLang 2000 (which, admittedly, has a surprisingly slick 
transparent distributed model, IckySmear).


When you're considering XML for a particular real-world case, it might 
be helpful to try to think through scenarios of using XML vs. other 
plausible open standards or semi-standards, like Protobuf, or some 
convention over JSON or CSV.  Who all will be on the other end of the 
interface?  How will they implement it?  What's everything that happens 
when the interface spec gets a new version?  How messy is that going to 
be?  How long does this have to keep working (e.g., medical records that 
might need to be interpreted perfectly 100 years and 10 corporate 
acquisitions later)?  Etc.


BTW, if you do go with XML, you might find RELAX NG Compact syntax to be 
pleasant.  And/or you could make a schema DSL in Racket that generates 
both various Racket interface code and the XML schemas in standard 
format, and maybe a SQL schema mapping, too (maybe even have your Racket 
DSL also generate some Java code shim for a customer's other system's 
proprietary plugin interface, while you otherwise move the larger system 
to open standard interfaces).


--
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] Real-world examples of XML usage?

[David Storrs]

There was a discussion in another thread lately about various ways of
representing XML.  It got me thinking, and I wanted to ask about
people's practical experience.

What projects have y'all done where XML was the best choice for a
reason other than "because we needed to interoperate with a service
that required XML"?

I've never needed to use XML that much -- HTML and CSS for the
browser, JSON for the wire, SQLite or Postgres for the DB, and (on one
rather memorable occasion) Postscript for the printer.  I'm aware of
the various technologies around XML -- XPATH, XSLT, etc -- but they
haven't featured in any project I've ever needed to do, so I haven't
spent much time on them.  Is that that's something I should find time
for?

I'm aware of two primary features that XML proponents point to for why
XML is worth knowing:  It's self-describing and it's typed.  To me,
the first sounds like a security nightmare of sophistry.  (Real-world
applications are typically going to know the format of the data that
they're consuming, and you certainly do not want to let external data
specify what standards and formats it should be held to.)  The ability
to type data (e.g. specify that 'age' elements are measured in days,
or years, or etc) is a good feature, and I'll give XML that one.

On the other hand, XML is extremely heavyweight, thereby slowing
parsing and transmission as well as making the data less
human-readable.

Are there angles here that I haven't encountered or thought about yet?
 If so, what would you recommend I read up on / look into?

-- 
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] Python's append vs Racket's append and helping novices understand the implications

[Alex Harsanyi]

I put together some notes about available data structures in Racket, with 
some performance considerations.  It needs more work, but perhaps it can be 
used as a starting point and it can be added to the Racket wiki, if/when 
others consider it adequate:

https://gist.github.com/alex-hhh/3cc5690a7f9c74543dab6c11344e6202

I didn't write a "Python to Racket" guide, because I don't really know 
enough about Python to write such a document, and I also think that a more 
generic document is simpler to maintain and can be used by people who come 
from other languages as well.

I also tried to keep the document short, the aim being to provide a 
competent programmer who is new to Racket with a 5 minute overview to its 
data structures and some links to the starting points in the 
documentation.  We can add things to it, but I think it is better to keep 
it short rather than comprehensive in this case -- after all, there is the 
Racket Guide and Racket Reference and these documents contain all the 
details.  Perhaps new documents can be added to the wiki, exploring other 
topics in more detail.

I did not mention `ralist` because (1) I have no experience with it, but 
more importantly (2) the package is not part of the Racket distribution and 
has to be installed separately.  I don't it reflects well on Racket if we 
tell people to install a separate package if they want an efficient 
container...  I have no experience with `ralist`, but if it is indeed a 
good data structure and it has a potentially wide usage, it should be 
included in the default Racket installation.

Alex.

On Sunday, February 3, 2019 at 7:00:10 AM UTC+8, Matthias Felleisen wrote:
>
>
>
> Racket needs *you*. Please. 
>
> The proper approach is to have short pages for different language 
> immigration groups: Python and R come to mind as obvious examples but I am 
> sure there are others. 
>
> What I mean is we need help and *you* can help. Let me explain it with the 
> Python example: 
>
> 1. Set up a page (wiki?) called “From Python to Racket” 
>
> 2. Create two sections that are immediately visible from the top: 
>  
> — idioms 
> — performance pitfalls 
>
> 3. In the specific case of Python, the second subsection needs to start 
> with a subsection on 
>
> — Python Lists aren’t Racket Lists 
> — then point to data/ralis and show how to transliterate the 
> loop/append example like this 
> — optionally also show the more native Racket idiom 
>
> 4. When anyone observers another blog/social media/whatever post on Racket 
> is slow because I come from Python, 
>
> (a) point the posters to the page  or 
> (b) if it is a new case, write a section for this example then do 
> (a) 
>
>
> If you want to help advertise Racket to others, this is an excellent way 
> of helping out. 
>
> Thanks — Matthias 
>
> [[ p.s. For my very first Python program (a couple of days before meeting 
> with GvR), I used Python’s append and was annoyed beyond belief. ]] 
>
>
>

-- 
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] Why would a value produced by eval-ing code not satisfy its type predicate? (Particularly, a SQL statement from the sql package)

[hashim muqtadir]

>  The issue you're encountering with namespaces is analogous, because each 
namespace gets its own instances of modules. This is a feature! Imagine, 
for example, that you are trying to run students' programs in a sandbox. If 
namespaces shared module instances, a malicious or buggy student program 
could alter mutable state and affect other students' programs or your 
outside-the-sandbox program. But this means that two different namespaces 
will have two distinct instances of the `sql` module that export two 
distinct `sql-statement?` predicates, each recognizing only its own version 
of the sql-statement struct type: this is effectively the same situation as 
calling `thing1?` on `a-thing2` in my example.

> For times when you really do want to share a module instance, Racket 
provides `namespace-attach-module`. Alternatively, you could just use 
`define-namespace-anchor` and `namespace-anchor->namespace`.

Thanks! That both explains and resolves the issue.

In my original example, if I replace the beginning part with:

#lang racket

(require db)
(require sql)

(define sql-namespace (make-base-empty-namespace))
(define src-namespace (current-namespace))
(parameterize ([current-namespace sql-namespace])
  (namespace-attach-module src-namespace 'sql)
  (namespace-require 'sql))

Then everything works as expected, and now I know why.

> But, as others have said, you really don't want to use `eval`. (If you 
aren't already familiar with the issues, see [...]

Point taken. At the time I just wanted the variable-columns thing working 
and I hadn't figured out how to make it work with a list. Additionally, 
escaping column names isn't going to be an issue, because most likely in 
the actual use case the user's required column list will pass through a 
whitelist. That part's solved, one way or another.

> As long as you at least know the schema you're working with, you could 
even generate select statements for all possible sets of columns at compile 
time, and then just choose the right statement dynamically with a runtime 
function.

That did occur to me, and was my other idea compared to eval, up until I'd 
figured out the INJECT thing, but I didn't do it as then there would be a 
huge amount of select statements. The idea was to basically take the column 
list, sort it, string-join, and then get the relevant select from a hash 
table. But there'd be way too many.

As to why I would like to do this, well, basically at my workplace we sort 
of make web applications, generally split into a separate server side 
application that's basically an HTTP API, that different browser and mobile 
applications talk to. I've previously always written the server side part 
in python. "Sort of" because have to work offline too.

One of the problems we face is of moving too much data around. Mobile 
applications that have to mainly work offline and periodically sync, they 
have to move around lots of data on horrible connections. (We do gzip and 
all. Choosing a data format that's not json is an option I'll evaluate in 
the future.)

So selecting a list of fields when getting data for different entites is 
something we provide in our APIs. In the beginning we did in fact return 
all of an entity's data. as writing different column sets for different 
clients, while do-able, is sort of bad in the sense that then when somebody 
asks for adding a column in a table in the mobile app, it required changes 
in two places, and needlessly adds code. The idea being that when we only 
write a different column set (and call it a different entity) on the same 
enttiy when it's a non trivial thing to do.

So anyway while most of this is solved for the current few projects we 
have, we're moving away from python. Racket's an experiment, partly chosen 
because we agree with the "many languages" approach. Things like python's 
django, sqlalchemy and javascript's vue aren't libraries, they're #langs. 
So now I have to write solutions/languages in Racket to make sure we're at 
least on par with what we have at the moment. Like in python we have our 
little filters language, which piggybacks on django ORM's column and 
relation lookup syntax, but we restrict some operations and add some 
others, nest them in and/or/not operators, and generically handle edge 
cases that django doesn't (like ensuring that joins don't increase row 
count). And no, writing SQL in the client application is not (yet) an 
option as we need to evaluate certain things first. Evaluated graphQL, a 
bit, tentatively, and alone, it doesn't to fit the use case. A hybrid 
approach seems do-able in the short term but a bad idea in the long term.

Anyway, thanks for the help. and I suppose I should mark this thread as 
solved (I don't know what that really does). I don't mind people asking 
things, but I suppose littering the list with specifics would be frowned 
upon.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To 

Re: [racket-users] Re: How To Design Classes text not available?

[Neil Van Dyke]

'John Clements' via Racket Users wrote on 2/2/19 5:18 PM:

Also, if you use duckduckgo as your default search engine, it looks like you 
can prepend !archive or !wayback


That leaks info to a dotcom for no reason.  If you don't use search 
engines except when they might add value, you might also want these 
Quick Searches:


Name: [SEARCH] DUCKDUCKGO
Location: https://start.duckduckgo.com/?q=%s=hb=-2=web
Keyword: d

Name: [SEARCH] DUCKDUCKGO IMAGES
Location: https://start.duckduckgo.com/?q=%s=hb=-2=images=images
Keyword: di

BTW, on the desktop, the browser operation to make new tab (Ctrl-T on my 
computer), with your new tab page set to blank, is a way to quickly both 
get a new browser tab without possibly disturbing something else, and to 
put your GUI text focus on the location bar do your next keystroke 
starts your Quick Search, autocomplete of your bookmarks, or a 
URL/domain.  No "new tab" or "search" or "home" page load, no separate 
search field widget taking up space that could show URL or slowing down 
the UI, no gratuitous/paid leaking.



  (turns out !a goes to amazon, sigh).


I took away my old "a" Quick Search keyword from Amazon, to give to 
Archive.org.  Individual users can still have some power over the 
computation they use. :)


--
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: performance: Racket vs Julia

[Neil Van Dyke]

Gour wrote on 2/2/19 3:55 PM:

Many languages simply do not pass 'GUI criteria' and, imho, Racket is very much 
deprived of its glory by providing first class GUI option for all those not so 
enamored with JS/browser stuff.


Yes, I did another look for Racket last year, and desktop GUI toolkit 
options generally seem to have have actually gotten fewer and worse 
since the move of most of the money to Web and handheld apps.  
(Regarding Web, right now it's dominated by snooping, and by 
brochure/tabloid HCI.  And, on handhelds and moving back to desktop, one 
could even wonder whether certain handheld UX designs being pushed on 
some developers for all apps are actually motivated not entirely by 
traditional HCI usability goals, but also against the users' interests, 
such as for combating the cognitive/perceptual filtering of ad 
placements that users learned almost immediately in the late-'90s, or to 
promote impulsive consumption of media "content".)



Some languages were simply excluded without even slight consideration like {C, 
C++, Java}, some are uninspiring (Go) or have (too) strange syntax etc.


We need to advertise this selling point for Racket: "Our syntax is not 
too strange!" :)


I understand the appeal of Racket, though of course there are good 
things to say about each of those languages you mentioned, both for 
novel PL merit and for practical application.  (I used the first 3 
heavily, in industry and/or research, and recently looked at the 4th, 
and would be happy using/developing it with the added incentive of gobs 
of money, though I currently prefer Racket for most purposes.)



1) is there a plan to fill the gap with the 'missing' widgets in the 
foreseeable future? (Iirc, someone once mentioned to me 'tree widget' which is 
not included out of the box.)


A core Racket person can speak about any plans for core.

What is super-useful for the community is when people develop some parts 
of their system as high-quality reusable components that are 
loosely-coupled with their application, and share those components as 
documented Racket packages.  This includes new GUI widgets.



2) how difficult is, in general, to add new widgets?


What I've done recently, as aggregations of existing components, for a 
retro smartphone UI, seemed mostly straightforward (and in this case was 
mostly a kind of coding that one can do for hours without having to 
think hard, so maybe it's a relaxing evening after a day of intense 
high-stakes software engineering :) (unreleased, for now) 
https://www.neilvandyke.org/postmarketos/


Another option for implementing new widgets in Racket is arbitrary 
drawing on a 2D or 3D canvas.  Or mixing arbitrary drawing and existing 
widgets (like you might want to do in a scalable editable 
spreadsheet/table widget, for example).  I haven't done this with Racket 
in a long time, but I think it's still reasonable, and you can look for 
examples in the Racket source code that don't proxy native toolkit 
components (e.g., the plot snip?).  But, by comparison, the JS widgets 
I've had to do from scratch more recently were a headache to make work 
well and be portable.


--
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: performance: Racket vs Julia

[Matthias Felleisen]

It is rare that I have to somewhat-contradict Matthew here, but so it goes. 

One of my colleagues, Jan Vitek, has studied Julia with a special focus on 
performance. As many have said, Julia is good at numerics because its compiler 
can specialize certain cases really well. More generally, it does well when a 
programmer commits to the effort of writing down performance-enhancing types. 
[1] BUT, there’s an incredible pitfall associated with this approach. If the 
programmer is a bit off with the types (not wrt correctness but wrt to 
narrowness or forgets to specify a type somewhere), the compiler still succeeds 
except that the program will be rather slow when uses certain paths [2]. So 
your performance experience with Julia could be quite varied. 

Use Racket for what you have in mind. It’s obviously the superior language :-) 

— Matthias

p.s. If there’s interest, I can dig out Jan’s draft paper. 


[1] Julia is gradually typed but it should really be considered optionally 
typed. The types are about performance, so they are more like C types than ML 
type.s 

[2] Julia’s compiler is tailor-made for an application of Vincent St-Amour’s 
dissertation research on feature-specific profiling. 

-- 
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] Python's append vs Racket's append and helping novices understand the implications

[Matthias Felleisen]

Racket needs *you*. Please. 

The proper approach is to have short pages for different language immigration 
groups: Python and R come to mind as obvious examples but I am sure there are 
others. 

What I mean is we need help and *you* can help. Let me explain it with the 
Python example: 

1. Set up a page (wiki?) called “From Python to Racket” 

2. Create two sections that are immediately visible from the top: 

— idioms 
— performance pitfalls 

3. In the specific case of Python, the second subsection needs to start with a 
subsection on 

— Python Lists aren’t Racket Lists 
— then point to data/ralis and show how to transliterate the 
loop/append example like this 
— optionally also show the more native Racket idiom 

4. When anyone observers another blog/social media/whatever post on Racket is 
slow because I come from Python, 

(a) point the posters to the page  or 
(b) if it is a new case, write a section for this example then do (a)


If you want to help advertise Racket to others, this is an excellent way of 
helping out. 

Thanks — Matthias

[[ p.s. For my very first Python program (a couple of days before meeting with 
GvR), I used Python’s append and was annoyed beyond belief. ]] 


-- 
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] "raco test" causes my reader to fail on carriage return (but newline works)

[Ryan Kramer]

I have a scribble document with a string representation of some code. The 
string is "(+ 1 2) \r\n (* 2 3)" which eventually gets sent through my 
reader.

When I run "Scribble HTML" in DrRacket it works. When I run "raco setup" it 
works. But when I run "raco test" my reader fails with

(exn:fail:read:eof "prog:2:0: read-syntax: expected a `)` to close `(`" 
# (list (srcloc 'prog 2 0 15 1)))

If I remove the \r so that the string is "(+ 1 2) \n (* 2 3)" then 
everything works, including "raco test".

My reader depends on (current-readtable) so my best guess is that "raco 
test" is modifying it before my reader runs. (Is there a way I can access 
the default readtable used by #lang racket, instead of using 
current-readtable? That would probably be better.)

Or maybe there is some parameter that controls newline handling?

I don't know a good way to debug this. Any suggestions and wild guesses are 
appreciated.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] How To Design Classes text not available?

[Matthias Felleisen]

http://felleisen.org/matthias/htdc.html 
 

[ The ccs.neu.edu  file is actually a redirect HTML file 
but that doesn’t seem to work. ]



> On Feb 2, 2019, at 3:26 PM, Justin Zamora  wrote:
> 
> I tried to download the draft of "How to Design Classes" from
> http://www.ccs.neu.edu/home/matthias/htdc.html and got a "Failed to
> load PDF document" error. Is this text still available?
> 
> Justin
> 
> -- 
> 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: How To Design Classes text not available?

['John Clements' via Racket Users]

Also, if you use duckduckgo as your default search engine, it looks like you 
can prepend !archive or !wayback (turns out !a goes to amazon, sigh).

John

> On Feb 2, 2019, at 14:08, Neil Van Dyke  wrote:
> 
> Justin Zamora wrote on 2/2/19 3:39 PM:
>> Thanks! I always forget about archive.org!
> 
> Semi-off-topic, but this is helpful for Racketeers recovering older Scheme 
> docs/discussion/code (some of the best thinking happened many years ago, and 
> is still relevant)...
> 
> Here's a useful Firefox Quick Search bookmark:
> 
> Name:  [SEARCH] ARCHIVE.ORG
> Location:  https://web.archive.org/web/%S
> Keyword:  a
> 
> Basically, whenever you get a normal Web decay 404 error, or some kind of 
> anti-abuse/anti-privacy blocking by the server, you can go to your browser's 
> location (URL) bar, and prepend "a" with a space, and press Enter/Return.  No 
> add-on required.  (Also, you might want to set the location bar to not send 
> your typing and mis-pastes to search engines, and to only do autocomplete 
> from your bookmarks, not from history or anything else.)
> 
> 
> (Aside: This is especially helpful if you're running through Tor with JS 
> disabled by default, because some useful news sites, especially, will 
> actively refuse to serve pages to a Tor exit node IP address with JS 
> disabled, and one popular CDN will also refuse to serve pages to this, 
> whether or not its site customers know it. Offhand, I can think of only one 
> news site that is Tor-hostile without usually having news articles readable 
> in Archive.org.  Note that you're leaking a bit to Archive.org and bugs it 
> runs, of course.)
> 
> (Further aside: I try, when mentioning Tor, not to inadvertently endorse it 
> too much, given that its security has often been overstated, which could be 
> very bad for people who actually desperately need that security... I've been 
> experimenting with using Tor mainly as a free low/moderate-security VPN for 
> most daily desktop Web browsing, because even sketchy and likely-compromised 
> Tor nodes have better reputations than my ISP, :) and for techie continual 
> learning, and sense of obligation.  I previously ran a proxy tunnel through 
> EC2 for this purpose, but that's not great, either, and I wanted to find a 
> solution for people who can't afford an extra ~$5/mo.  Tor seems not-great 
> against some sophisticated adversaries, though, and the situation seems 
> almost hopeless with the current de facto Web architecture -- without even 
> blackbox traffic analysis, potentially large numbers of compromised nodes, or 
> general endpoint vulnerabilities.  But it's good for a little privacy from 
> your awful ISP, open WiFi, etc., if you don't mind it being slow, and if, 
> like me, you are boring enough that you don't mind your mere use of Tor 
> presumably raising your profile a bit for actors more-sophisticated than your 
> ISP or compromised cafe/hotel WiFi.  Also, Tor Browser is more consistently 
> privacy than the other browsers, with possible wait 
> exception of Brave.  Example warning for more general audiences is on 
> "https://www.neilvandyke.org/replicant/;.)
> 
> -- 
> 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: How To Design Classes text not available?

[Neil Van Dyke]

Justin Zamora wrote on 2/2/19 3:39 PM:

Thanks! I always forget about archive.org!


Semi-off-topic, but this is helpful for Racketeers recovering older 
Scheme docs/discussion/code (some of the best thinking happened many 
years ago, and is still relevant)...


Here's a useful Firefox Quick Search bookmark:

Name:  [SEARCH] ARCHIVE.ORG
Location:  https://web.archive.org/web/%S
Keyword:  a

Basically, whenever you get a normal Web decay 404 error, or some kind 
of anti-abuse/anti-privacy blocking by the server, you can go to your 
browser's location (URL) bar, and prepend "a" with a space, and press 
Enter/Return.  No add-on required.  (Also, you might want to set the 
location bar to not send your typing and mis-pastes to search engines, 
and to only do autocomplete from your bookmarks, not from history or 
anything else.)



(Aside: This is especially helpful if you're running through Tor with JS 
disabled by default, because some useful news sites, especially, will 
actively refuse to serve pages to a Tor exit node IP address with JS 
disabled, and one popular CDN will also refuse to serve pages to this, 
whether or not its site customers know it. Offhand, I can think of only 
one news site that is Tor-hostile without usually having news articles 
readable in Archive.org.  Note that you're leaking a bit to Archive.org 
and bugs it runs, of course.)


(Further aside: I try, when mentioning Tor, not to inadvertently endorse 
it too much, given that its security has often been overstated, which 
could be very bad for people who actually desperately need that 
security... I've been experimenting with using Tor mainly as a free 
low/moderate-security VPN for most daily desktop Web browsing, because 
even sketchy and likely-compromised Tor nodes have better reputations 
than my ISP, :) and for techie continual learning, and sense of 
obligation.  I previously ran a proxy tunnel through EC2 for this 
purpose, but that's not great, either, and I wanted to find a solution 
for people who can't afford an extra ~$5/mo.  Tor seems not-great 
against some sophisticated adversaries, though, and the situation seems 
almost hopeless with the current de facto Web architecture -- without 
even blackbox traffic analysis, potentially large numbers of compromised 
nodes, or general endpoint vulnerabilities.  But it's good for a little 
privacy from your awful ISP, open WiFi, etc., if you don't mind it being 
slow, and if, like me, you are boring enough that you don't mind your 
mere use of Tor presumably raising your profile a bit for actors 
more-sophisticated than your ISP or compromised cafe/hotel WiFi.  Also, 
Tor Browser is more consistently privacy than the 
other browsers, with possible wait exception of Brave.  Example 
warning for more general audiences is on 
"https://www.neilvandyke.org/replicant/;.)


--
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: performance: Racket vs Julia

[Gour]

On Sat, 2 Feb 2019 08:04:36 -0700
Matthew Flatt  wrote:

> It's possible that the someone talked to me. I recall offering the
> opinion to someone at RacketCon/ICFP/StrangeLoop that Racket would not
> be as fast as Julia for the case that Julia is designed for ---
> specifically numerics --- due to the way the Julia compiler
> specializes programs to numeric types and hands off to LLVM as its
> back end. 

Hey, but that's not fair!! The 'quote' is pulled out of the context. :-(

> But I agree with others that Racket is likely to be faster on most things.

Thank a million!! It does help me very much to make a decison. ;)


Sincerely,
Gour

-- 
Whenever and wherever there is a decline in religious practice,
O descendant of Bharata, and a predominant rise of irreligion —
at that time I descend Myself.


-- 
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: performance: Racket vs Julia

[Gour]

On Sat, 2 Feb 2019 04:53:33 -0500
Neil Van Dyke  wrote:

> That's an unusual shortlist of candidates.  

Well, yes and no. Many languages simply do not pass 'GUI criteria' and, imho,
Racket is very much deprived of its glory by providing first class GUI option
for all those not so enamored with JS/browser stuff.

Some languages were simply excluded without even slight consideration like {C,
C++, Java}, some are uninspiring (Go) or have (too) strange syntax etc.

>  Does this desktop app do heavy numeric computation?  

Yes, it's supposed to crunch the numbers, but I plan to use 3rd party C library
for that and then just provide higher-level bindings to if from the host
language and write custom libraries which use functions from the C lib on top
of that.
 
> Or is your organization already invested i n Julia for numeric, and you'd
> like to also use it for GUI if you can?

No, it is supposed to be open-source hobby project, so there must be some fun
doing it. I also would like to avoid "2 language problem" in regard to GUI.

> Maybe a year or two ago, I asked about Julia for systems-ish
> programming (like low-level operating systems code, and
> high-performance server I/O), and, at the time, it sounded like the
> performance for that was not there -- Julia was initially focused on
> numeric performance.

It also seems that Julia does not want to be too 'general programming
language'. :-)

> Note that a few things DrRacket does are more compute-intensive than most
> desktop apps (such as evaluating child programs with debugging info), but you
> can get an idea.

Ohh, that's very helpful. Thank you very much for this insight.

> 2. Look in the Racket documentation for what the cross-platform GUI
> toolkit (and the separate "Framework" stuff) provide.  They provide
> th e usual basic widgets, plus some non-usual DrRacket editor
> functionality, but they don't have as much widgets as some toolkits
> have (so make sure it has what you need, or be prepared to code
> what's missing). https://docs.racket-lang.org/gui/Widget_Gallery.html
> https://docs.racket-lang.org/gui/Windowing_Classes.html
> https://docs.racket-lang.org/framework/index.html

Two questions in regard:

1) is there a plan to fill the gap with the 'missing' widgets in the
foreseeable future? (Iirc, someone once mentioned to me 'tree widget' which is
not included out of the box.)

2) how difficult is, in general, to add new widgets?

> If you have numeric performance requirements (if that's why you're
> looking at Julia), 

Julia seems to me as interesting language - in the past I was also looking at
Dylan - and numeric performance is not the main reason behind my interest, but
e.g. Python is certainly too slow as proved by some people trying to
write similar apps and abandoning it to eventually go e.g C++.

> Or do you want to try coding those functions in Typed Racket?

Based on what I read, Typed Racket is something I want to explore.

> That's when someone says "Challenge accepted." :)

:-)

Thank you for shedding the light on this issues.


Sincerely,
Gour

-- 
As fire is covered by smoke, as a mirror is covered by dust,
or as the embryo is covered by the womb, the living entity is
similarly covered by different degrees of this lust.


-- 
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: How To Design Classes text not available?

[Justin Zamora]

Thanks! I always forget about archive.org!

Justin

On Sat, Feb 2, 2019 at 3:29 PM Greg Trzeciak  wrote:
>
> Try
>
> https://web.archive.org/web/20181228174204/http://www.ccs.neu.edu/home/matthias/HtDC/htdc.pdf
>
> On Saturday, February 2, 2019 at 9:26:15 PM UTC+1, Justin Zamora wrote:
>>
>> I tried to download the draft of "How to Design Classes" from
>> http://www.ccs.neu.edu/home/matthias/htdc.html and got a "Failed to
>> load PDF document" error. Is this text still available?
>>
>> Justin
>
> --
> 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: performance: Racket vs Julia

[Gour]

On Sat, 2 Feb 2019 01:41:17 -0800 (PST)
Yvan Godin  wrote:

> I have played with Julia as a language it's a good compromise between Common
> Lisp with Python syntax and C performance
> 
> but build an autonomous prog. come with a lot of pain

That's good to know. Thank you!

> their Gtk is far to be well finished and polished as many other  libraries
> but this is a matter of time

 OK.

> so I continue to love Racket even if will remain for long time a little bit
> less performant  but that depend on your needs

:-)

> only my feeling and sorry for my low skilled English ;-)

I dіdn't notice it and your message went through. ;)


Sincerely,
Gour

-- 
But for one who takes pleasure in the self, whose human life
is one of self-realization, and who is satisfied in the self only,
fully satiated — for him there is no duty.


-- 
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: How To Design Classes text not available?

[Greg Trzeciak]

Try

https://web.archive.org/web/20181228174204/http://www.ccs.neu.edu/home/matthias/HtDC/htdc.pdf

On Saturday, February 2, 2019 at 9:26:15 PM UTC+1, Justin Zamora wrote:
>
> I tried to download the draft of "How to Design Classes" from 
> http://www.ccs.neu.edu/home/matthias/htdc.html and got a "Failed to 
> load PDF document" error. Is this text still available? 
>
> Justin 
>

-- 
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] How To Design Classes text not available?

[Justin Zamora]

I tried to download the draft of "How to Design Classes" from
http://www.ccs.neu.edu/home/matthias/htdc.html and got a "Failed to
load PDF document" error. Is this text still available?

Justin

-- 
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] Python's append vs Racket's append and helping novices understand the implications

[Philip McGrath]

I am certain people coming from Python are confused by this, since I was
bitten by this very difference when I had to write some Python for the
first time in a while. (What do you mean append has side-effects?!?)

-Philip


On Sat, Feb 2, 2019 at 10:30 AM Robby Findler 
wrote:

> On Sat, Feb 2, 2019 at 9:23 AM George Neuner  wrote:
> >
> >
> > On 2/2/2019 9:38 AM, Robby Findler wrote:
> > > Lists seem like a common pitfall here, due to the overlap in
> > > terminology but not functionality/performance. Maybe the right thing
> > > is to add a library to data/ that is the python list data
> > > structure and point to it from the list documentation?
> >
> > The problem is that a Python "list" isn't a list at all - it's an
> > extensible vector of pointers.  Perhaps the right thing is to educate
> > Pythonistas that they really haven't been using lists.
>
> Although eduction is certainly a good goal(!), that seems like the
> long path to the helpful result for us. :)
>
> Robby
>
> --
> 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] performance: Racket vs Julia

[George Neuner]

On 2/2/2019 10:04 AM, Matthew Flatt wrote:

At Sat, 2 Feb 2019 10:04:04 +0100, Gour wrote:
> Leaving aside other language features' pros/cons, I was a bit surprised
> when someone in Julia's channel responded to me with: "Racket is pretty
> amazing, but I stopped looking into it after I figured, that it can't
> really be made fast language...I just talked at some point with some of
> the core devs, and they told me that racket may never be julia fast
> (some of them actually know julia quite well)".

It's possible that the someone talked to me. I recall offering the
opinion to someone at RacketCon/ICFP/StrangeLoop that Racket would not
be as fast as Julia for the case that Julia is designed for ---
specifically numerics --- due to the way the Julia compiler specializes
programs to numeric types and hands off to LLVM as its back end. But I
agree with others that Racket is likely to be faster on most things.


Nevertheless, it would be nice if Racket could use SIMD for typed 
vector/array math.  Trying to beat Julia at numerics is a losing 
proposition, but Racket certainly could do better.


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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Python's append vs Racket's append and helping novices understand the implications

[Robby Findler]

On Sat, Feb 2, 2019 at 9:23 AM George Neuner  wrote:
>
>
> On 2/2/2019 9:38 AM, Robby Findler wrote:
> > Lists seem like a common pitfall here, due to the overlap in
> > terminology but not functionality/performance. Maybe the right thing
> > is to add a library to data/ that is the python list data
> > structure and point to it from the list documentation?
>
> The problem is that a Python "list" isn't a list at all - it's an
> extensible vector of pointers.  Perhaps the right thing is to educate
> Pythonistas that they really haven't been using lists.

Although eduction is certainly a good goal(!), that seems like the
long path to the helpful result for us. :)

Robby

-- 
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] Python's append vs Racket's append and helping novices understand the implications

[George Neuner]

On 2/2/2019 9:38 AM, Robby Findler wrote:
Lists seem like a common pitfall here, due to the overlap in 
terminology but not functionality/performance. Maybe the right thing 
is to add a library to data/ that is the python list data 
structure and point to it from the list documentation?


The problem is that a Python "list" isn't a list at all - it's an 
extensible vector of pointers.  Perhaps the right thing is to educate 
Pythonistas that they really haven't been using lists.


I know nuances are lost on most people, but there's a huge difference 
between a list and a vector.


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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Python's append vs Racket's append and helping novices understand the implications

[Sam Tobin-Hochstadt]

I agree with that 100%.

On Sat, Feb 2, 2019, 9:46 AM Robby Findler  Oh, right! Mentioning python in the list docs seems like it might help.
>
> Robby
>
> On Sat, Feb 2, 2019 at 8:45 AM Sam Tobin-Hochstadt 
> wrote:
>
>> Fortunately there are already libraries with good performance on these
>> operations for Racket, so we could point to the data/ralist library,
>> for example.
>>
>> Sam
>>
>> On Sat, Feb 2, 2019 at 9:38 AM Robby Findler
>>  wrote:
>> >
>> > Lists seem like a common pitfall here, due to the overlap in
>> terminology but not functionality/performance. Maybe the right thing is to
>> add a library to data/ that is the python list data structure
>> and point to it from the list documentation?
>> >
>> > Robby
>> >
>> > On Sat, Feb 2, 2019 at 12:28 AM Alex Harsanyi 
>> wrote:
>> >>
>> >> Someone asked recently for help on Reddit[1] with a Racket performance
>> issue.
>> >> The problem was they they were constructing a large list by appending
>> many
>> >> short lists repeatedly; their code was calling `(set!  result (append
>> result
>> >> shortList))` in a loop and this was slow (unsurprisingly.)
>> >>
>> >> While trying to help them out, it occurred to me that this person was
>> perhaps
>> >> translating a program from Python to Racket, maybe to evaluate
>> Racket.  The
>> >> problem is that list-append operations are efficient in Python, but the
>> >> natural corresponding choice in Racket, the `append` function, is
>> not.  I
>> >> wonder how many people are in a similar situation, where they try to
>> convert a
>> >> Python program to Racket, see that the performance is bad, and
>> conclude that
>> >> Racket is slow -- Every time Racket is mentioned on Reddit or HN there
>> is at
>> >> least one person mentioning that Racket is slow and sadly they may
>> even have
>> >> their own data to prove it.
>> >>
>> >> Given the recent discussion in this group about promoting Racket, I am
>> >> wondering what can we do to help this category of people?  These might
>> be
>> >> persons who never ask for help in any forum, after all the Racket
>> >> documentation is good enough to help anyone who is willing to read it.
>> >>
>> >> One improvement that I can think of is to add a performance
>> description to
>> >> each function that operates on the basic data structures (lists,
>> vectors,
>> >> hash-tables)
>> >>
>> >> What do others think?
>> >> Alex.
>> >>
>> >> [1]:
>> https://www.reddit.com/r/Racket/comments/am5r2w/how_to_read_a_file_linebyline_efficiently/
>> >>
>> >> --
>> >> 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.
>>
> --
> 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] performance: Racket vs Julia

[Matthew Flatt]

At Sat, 2 Feb 2019 10:04:04 +0100, Gour wrote:
> Leaving aside other language features' pros/cons, I was a bit surprised
> when someone in Julia's channel responded to me with: "Racket is pretty
> amazing, but I stopped looking into it after I figured, that it can't
> really be made fast language...I just talked at some point with some of
> the core devs, and they told me that racket may never be julia fast
> (some of them actually know julia quite well)".

It's possible that the someone talked to me. I recall offering the
opinion to someone at RacketCon/ICFP/StrangeLoop that Racket would not
be as fast as Julia for the case that Julia is designed for ---
specifically numerics --- due to the way the Julia compiler specializes
programs to numeric types and hands off to LLVM as its back end. But I
agree with others that Racket is likely to be faster on most things.

-- 
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] Python's append vs Racket's append and helping novices understand the implications

[Robby Findler]

Oh, right! Mentioning python in the list docs seems like it might help.

Robby

On Sat, Feb 2, 2019 at 8:45 AM Sam Tobin-Hochstadt 
wrote:

> Fortunately there are already libraries with good performance on these
> operations for Racket, so we could point to the data/ralist library,
> for example.
>
> Sam
>
> On Sat, Feb 2, 2019 at 9:38 AM Robby Findler
>  wrote:
> >
> > Lists seem like a common pitfall here, due to the overlap in terminology
> but not functionality/performance. Maybe the right thing is to add a
> library to data/ that is the python list data structure and
> point to it from the list documentation?
> >
> > Robby
> >
> > On Sat, Feb 2, 2019 at 12:28 AM Alex Harsanyi 
> wrote:
> >>
> >> Someone asked recently for help on Reddit[1] with a Racket performance
> issue.
> >> The problem was they they were constructing a large list by appending
> many
> >> short lists repeatedly; their code was calling `(set!  result (append
> result
> >> shortList))` in a loop and this was slow (unsurprisingly.)
> >>
> >> While trying to help them out, it occurred to me that this person was
> perhaps
> >> translating a program from Python to Racket, maybe to evaluate Racket.
> The
> >> problem is that list-append operations are efficient in Python, but the
> >> natural corresponding choice in Racket, the `append` function, is not.
> I
> >> wonder how many people are in a similar situation, where they try to
> convert a
> >> Python program to Racket, see that the performance is bad, and conclude
> that
> >> Racket is slow -- Every time Racket is mentioned on Reddit or HN there
> is at
> >> least one person mentioning that Racket is slow and sadly they may even
> have
> >> their own data to prove it.
> >>
> >> Given the recent discussion in this group about promoting Racket, I am
> >> wondering what can we do to help this category of people?  These might
> be
> >> persons who never ask for help in any forum, after all the Racket
> >> documentation is good enough to help anyone who is willing to read it.
> >>
> >> One improvement that I can think of is to add a performance description
> to
> >> each function that operates on the basic data structures (lists,
> vectors,
> >> hash-tables)
> >>
> >> What do others think?
> >> Alex.
> >>
> >> [1]:
> https://www.reddit.com/r/Racket/comments/am5r2w/how_to_read_a_file_linebyline_efficiently/
> >>
> >> --
> >> 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.
>

-- 
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] Python's append vs Racket's append and helping novices understand the implications

[Sam Tobin-Hochstadt]

Fortunately there are already libraries with good performance on these
operations for Racket, so we could point to the data/ralist library,
for example.

Sam

On Sat, Feb 2, 2019 at 9:38 AM Robby Findler
 wrote:
>
> Lists seem like a common pitfall here, due to the overlap in terminology but 
> not functionality/performance. Maybe the right thing is to add a library to 
> data/ that is the python list data structure and point to it from 
> the list documentation?
>
> Robby
>
> On Sat, Feb 2, 2019 at 12:28 AM Alex Harsanyi  wrote:
>>
>> Someone asked recently for help on Reddit[1] with a Racket performance issue.
>> The problem was they they were constructing a large list by appending many
>> short lists repeatedly; their code was calling `(set!  result (append result
>> shortList))` in a loop and this was slow (unsurprisingly.)
>>
>> While trying to help them out, it occurred to me that this person was perhaps
>> translating a program from Python to Racket, maybe to evaluate Racket.  The
>> problem is that list-append operations are efficient in Python, but the
>> natural corresponding choice in Racket, the `append` function, is not.  I
>> wonder how many people are in a similar situation, where they try to convert 
>> a
>> Python program to Racket, see that the performance is bad, and conclude that
>> Racket is slow -- Every time Racket is mentioned on Reddit or HN there is at
>> least one person mentioning that Racket is slow and sadly they may even have
>> their own data to prove it.
>>
>> Given the recent discussion in this group about promoting Racket, I am
>> wondering what can we do to help this category of people?  These might be
>> persons who never ask for help in any forum, after all the Racket
>> documentation is good enough to help anyone who is willing to read it.
>>
>> One improvement that I can think of is to add a performance description to
>> each function that operates on the basic data structures (lists, vectors,
>> hash-tables)
>>
>> What do others think?
>> Alex.
>>
>> [1]: 
>> https://www.reddit.com/r/Racket/comments/am5r2w/how_to_read_a_file_linebyline_efficiently/
>>
>> --
>> 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] Python's append vs Racket's append and helping novices understand the implications

[Robby Findler]

Lists seem like a common pitfall here, due to the overlap in terminology
but not functionality/performance. Maybe the right thing is to add a
library to data/ that is the python list data structure and
point to it from the list documentation?

Robby

On Sat, Feb 2, 2019 at 12:28 AM Alex Harsanyi 
wrote:

> Someone asked recently for help on Reddit[1] with a Racket performance
> issue.
> The problem was they they were constructing a large list by appending many
> short lists repeatedly; their code was calling `(set!  result (append
> result
> shortList))` in a loop and this was slow (unsurprisingly.)
>
> While trying to help them out, it occurred to me that this person was
> perhaps
> translating a program from Python to Racket, maybe to evaluate Racket.  The
> problem is that list-append operations are efficient in Python, but the
> natural corresponding choice in Racket, the `append` function, is not.  I
> wonder how many people are in a similar situation, where they try to
> convert a
> Python program to Racket, see that the performance is bad, and conclude
> that
> Racket is slow -- Every time Racket is mentioned on Reddit or HN there is
> at
> least one person mentioning that Racket is slow and sadly they may even
> have
> their own data to prove it.
>
> Given the recent discussion in this group about promoting Racket, I am
> wondering what can we do to help this category of people?  These might be
> persons who never ask for help in any forum, after all the Racket
> documentation is good enough to help anyone who is willing to read it.
>
> One improvement that I can think of is to add a performance description to
> each function that operates on the basic data structures (lists, vectors,
> hash-tables)
>
> What do others think?
> Alex.
>
> [1]:
> https://www.reddit.com/r/Racket/comments/am5r2w/how_to_read_a_file_linebyline_efficiently/
>
> --
> 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] Python's append vs Racket's append and helping novices understand the implications

[Thomas F. Burdick]

On February 2, 2019 7:28:12 AM GMT+01:00, Alex Harsanyi 
 wrote:
>Someone asked recently for help on Reddit[1] with a Racket performance 
>issue.
>The problem was they they were constructing a large list by appending
>many
>short lists repeatedly; their code was calling `(set!  result (append
>result
>shortList))` in a loop and this was slow (unsurprisingly.)

In addition to the general list-processing advice they were likely given, I 
suspect someone coming from Python might appreciate tconc structures. SRFI 117 
is one attempt at fleshing this out into a contemporary API. But just classic 
tconc and lconc are pretty useful to know and have at your fingertips.

-Thomas

-- 
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] performance: Racket vs Julia

[Neil Van Dyke]

Gour wrote on 2/2/19 4:04 AM:

I've to decide between Racket and Julia as language of choice for writing 
desktop app. Racket's advantage is that its GUI support is provided out of the 
box, while in Julia I'd probably have to use Gtk.jl as the best supported 
package since I do not want to use Electron or some other JS/browser-based 
things.


That's an unusual shortlist of candidates.  Does this desktop app do 
heavy numeric computation?  Or is your organization already invested in 
Julia for numeric, and you'd like to also use it for GUI if you can?


Maybe a year or two ago, I asked about Julia for systems-ish programming 
(like low-level operating systems code, and high-performance server 
I/O), and, at the time, it sounded like the performance for that was not 
there -- Julia was initially focused on numeric performance.


If you want to evaluate Racket for desktop GUI apps, I suggest:

1. Try DrRacket on all your platforms, and see how responsive and how 
platform-native-looking the widgets are on those.  Note that a few 
things DrRacket does are more compute-intensive than most desktop apps 
(such as evaluating child programs with debugging info), but you can get 
an idea.


2. Look in the Racket documentation for what the cross-platform GUI 
toolkit (and the separate "Framework" stuff) provide.  They provide the 
usual basic widgets, plus some non-usual DrRacket editor functionality, 
but they don't have as much widgets as some toolkits have (so make sure 
it has what you need, or be prepared to code what's missing).

https://docs.racket-lang.org/gui/Widget_Gallery.html
https://docs.racket-lang.org/gui/Windowing_Classes.html
https://docs.racket-lang.org/framework/index.html

If you have numeric performance requirements (if that's why you're 
looking at Julia), are those functions covered by particular libraries 
you might call from Racket from C, Fortran, or R?  Or do you want to try 
coding those functions in Typed Racket?



Leaving aside other language features' pros/cons, I was a bit surprised when someone 
in Julia's channel responded to me with: "Racket is pretty amazing, but I 
stopped looking into it after I figured, that it can't really be made fast 
language...


That's when someone says "Challenge accepted." :)

But seriously, the question then is "Fast *for what*?"

BTW, I've run Racket on old WiFi routers and old smartphones:
https://www.neilvandyke.org/racket-openwrt/
https://www.neilvandyke.org/postmarketos/

--
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: performance: Racket vs Julia

[Yvan Godin]

Hello
I have played with Julia
as a language it's a good compromise between Common Lisp with Python syntax 
and C performance

but build an autonomous prog. come with a lot of pain

Racket come with an excellent battery include

Julia is based on LLVM witch is very very  big
Julia provide a real 'live coding' that's not the case for Racket 
Julia libraries space is much more oriented for heavy scientific 
calculation but there not good general programing tools, their Gtk is far 
to be well finished and polished as many other  libraries but this is a 
matter of time

so I continue to love Racket even if will remain for long time a  little 
bit less performant  but that depend on your needs

only my feeling and sorry for my low skilled English ;-)

Le samedi 2 février 2019 10:04:22 UTC+1, Gour a écrit :
>
> Hello, 
>
> I've to decide between Racket and Julia as language of choice for writing 
> desktop app. Racket's advantage is that its GUI support is provided out of 
> the 
> box, while in Julia I'd probably have to use Gtk.jl as the best supported 
> package  since I do not want to use Electron or some other 
> JS/browser-based 
> things. 
>
> Leaving aside other language features' pros/cons, I was a bit surprised 
> when someone in Julia's channel responded to me with: "Racket is pretty 
> amazing, but I stopped looking into it after I figured, that it can't 
> really be made fast language...I just talked at some point with some of 
> the core devs, and they told me that racket may never be julia fast 
> (some of them actually know julia quite well)". I received some 
> feedback on it in Slack's channel, but curious to receive some more 
> here. iow. whether "Racket may never be Julia fast" can be taken in 
> general or it is just a question from case to case? 
>
>
> Sincerely, 
> Gour 
>
> -- 
> As the embodied soul continuously passes, in this body, 
> from boyhood to youth to old age, the soul similarly passes 
> into another body at death. A sober person is not bewildered 
> by such a change. 
>
>
>

-- 
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] performance: Racket vs Julia

[Gour]

Hello,

I've to decide between Racket and Julia as language of choice for writing
desktop app. Racket's advantage is that its GUI support is provided out of the
box, while in Julia I'd probably have to use Gtk.jl as the best supported
package  since I do not want to use Electron or some other JS/browser-based
things.

Leaving aside other language features' pros/cons, I was a bit surprised
when someone in Julia's channel responded to me with: "Racket is pretty
amazing, but I stopped looking into it after I figured, that it can't
really be made fast language...I just talked at some point with some of
the core devs, and they told me that racket may never be julia fast
(some of them actually know julia quite well)". I received some
feedback on it in Slack's channel, but curious to receive some more
here. iow. whether "Racket may never be Julia fast" can be taken in
general or it is just a question from case to case?


Sincerely,
Gour 

-- 
As the embodied soul continuously passes, in this body,
from boyhood to youth to old age, the soul similarly passes
into another body at death. A sober person is not bewildered
by such a change.


-- 
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] Python's append vs Racket's append and helping novices understand the implications

[Neil Van Dyke]

Alex Harsanyi wrote on 2/2/19 1:28 AM:
One improvement that I can think of is to add a performance 
description to each function that operates on the basic data 
structures (lists, vectors, hash-tables)


Before complete coverage, perhaps two first steps:

* Try to think of the minority of procedures (and use cases?) that might 
be *surprisingly* expensive (either to anyone, or to users coming from 
some other languages), and focus first on the documentation for those.  
`append` is likely one, for people who don't yet understand lists well, 
or who aren't aware of more efficient patterns/idioms.  `list?` (or 
`listp` elsewhere in our Lisp family) is one that bit me and others, 
somehow not realizing it's potentially O(n) [1] (though apparently 
Racket now optimizes some cases of that, for immutable pairs[2]).  Those 
are the first two that come to mind, but I assume someone would find 
others by looking methodically through the documentation.


* Exposing lists based on pairs means programmers must understand the 
list model (list is not an opaque abstract data type), and it'll help 
them if they know some patterns for working with the model. Teach every 
Racketeer some old-school list processing.[3][4]  Maybe teach this 
before `for`-something (before they think "Aha!  Now I know the Racket 
way, which is pretty much the same as in many other languages I know!", 
and then they consider the finer points of lists and recursion to be 
esoteric stuff that maybe they don't learn well, soon).



[1] The current documentation even hides the recursive mathematical 
definition of a list in innocent-looking text, trying to trick users 
into the classic mistake! :)


[2] It looks like Racket C code now sometimes stores a bit with 
immutable pairs to cache list-ness, though the documentation's exact 
characterization of the performance of this isn't obvious from the C 
function alone.  Also, I don't see where in that function the 
PAIR_IS_NON_LIST flag is checked, for optimizing those cases. (BTW,


[3] https://m.xkcd.com/297/

[4] One day, I got all excited by Roombas, and accidentally typed an 
alist primer. 
https://www.neilvandyke.org/racket/roomba/#%28part._.Association._.List._.Primer%29


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Why would a value produced by eval-ing code not satisfy its type predicate? (Particularly, a SQL statement from the sql package)

[George Neuner]

On 2/1/2019 5:12 AM, hashim muqtadir wrote:

> No.  Look back at your code ... you defined the struct in your own
> unnamed module just before the definition of "select/f"

But the thing is, the error was that it failed to recognize 
sql-statement in the test, which is provided by sql, not me. The 
function otherwise worked correctly. The thing returned by the 
function wasn't recognized as an sql-statement. It had the same 
printed representation as a call to "select" done manually.


If I remember correctly, you said the error was that the result didn't 
satisfy "sql-statement?".  That would happen if the struct was not 
recognized.


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.
For more options, visit https://groups.google.com/d/optout.