[racket-users] telling apart files ending with a newline

[Shriram Krishnamurthi]

Suppose I have two files that are identical, except one ends in a newline 
and the other does not. If I use `read-line` to read the successive lines 
of this file, because it swallows the line separators, there is no way to 
tell them apart. E.g., these two strings

"a
b"

and

"a
b
"

read using `read-line` and `open-input-string` produce the same result.

This is unfortunate for a program SPDEGabrielle has induced me to write (-:.

Any reasonable ways to work around this that rely, as much as possible, on 
the OS-specific handling `read-line` already provides?

Shriram

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/250c95c9-24b6-467a-ad08-0cd81abded66n%40googlegroups.com.

[racket-users] Quickscript competition Deadline Extended till Tuesday Morning 4 Aug (uk time)

[Stephen De Gabrielle]

Quickscript competition Deadline Extended till Tuesday Morning 4 Aug (uk time) 
https://github.com/Quickscript-Competiton/July2020entries

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/3988c7f0-b978-49f5-a9cb-26af1b34dfeeo%40googlegroups.com.

Re: [racket-users] Does Racket interpreter exist?

[zeRusski]

>
> -- hendrik 
>
> I hope this set of answers clarifies the distinction between an 
> interpeter and compiler, how the distinction gets blurred in practice, 
> and what the criteria are for choosng between them. 
>

This was both detailed, insightful and truly helpful. I can't thank you 
enough for taking the time Hendrik! I'm glad I pressed the matter.

Thank you

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

Re: [racket-users] Does Racket interpreter exist?

[Hendrik Boom]

On Wed, Jul 29, 2020 at 01:56:05AM -0700, zeRusski wrote:
> This is a really cool piece of history! Thank you.
> 
> I'll admit I'm somewhat fuzzy here - it maybe a bit too meta for me or 
> perhaps I don't quite understand what you're trying to say. Isn't 
> interpreting n levels deep also linear in n?

Answer 1.

Let's say, for example, that it takes 10 instructions executed in an 
interpreter to decode, take decisions, and execute an interpreted 
instruction.  (In real life this varies a lot between interpreters and 
between interpreted instructions but let's keep the example simple.)
(and, also to keep things simple, let's say the interpreter in 
interpreting the machine language of the machne it's running on -- 
not an unusual technique in a debugger.)

Then interpreting a program using an interpreter running on hardware 
would take ten times as long as executing the program on the same 
hardware.

And likewise, interpreting the program in an interpreter being 
interpreted by the interpeter running on the hardware would take another 
ten times as lng as just interpreting the program with an interpreter 
running on the hardware.  

Thus 10 x 10, times as slow; this is where the exponential comes in.

> Only difference between the 
> two approaches  I see is that compiler lets you persist the fruits of its 
> labor so you don't have to start from scratch every time. Couldn't you 
> accommodate this with an interpreter (with some effort) although at this 
> point it becomes a compiler I suppose. Definitely fuzzy here.

That is exactly the difference between a compiler and an interpreter.

Answer 2:

Time to muddy the situation.

There are mixed-style language implementations.

If you only execute each piece of code once, interpreters tend to be 
faster.  But if you are to execute code many times, it's faster to 
compile.  It takes time to compile, but you get it back by saving time 
in later executions.

So what thee mixed implementations to is to interpret the code, but 
keeping track how often each piece of code (such as a function) is 
called.

When the count reaches a particular threshold, it pauses interpretation 
and compiles that code, the compiled code to be used thereafter.

There is some time penalty over compilation, because you waste time 
interpreting functions several times before you compile them.
This is offset by not having to compile code that is used only a few 
times.

The time behaviour of this kind of system overall is more like a 
compiler than an interpreter because the code that is executed the most 
does eventually get compiled and the rest gets interpeted only a limited 
number of 
times.

However, if it were to execute a copy of its own code, it would have to 
recompile it, unless it had a mechanism to check if the newly input 
program is the same as one it has already compiled.  This isn't 
impossible, but is not usually done.

> 
> > But when going n levels deep, the total execution time with a compiler 
> > is linear in n, and with an interpreter it's exponential. 

I use this criterion to tell whether a particular implementation is more 
like an interpreter or a compiler.

> >
> > That makes interpreting interpreters impractical when n gets large (even 
> > with n around 3 or 4); whereas compiling compilers can be done even for 
> > larger n. 
> >

Answer 3.

On modern machines, it is also important to keep memory demands low.  
Accessing large amounts of memory regularly tends to push other data our 
of cache, or even out of RAM onto disk.

Conserving storage is a common reason for using interpreted bytecode as 
the target language for a compiler.  The bytecode is usually smaller 
than the machine language.  If the bytecode interpreter is small enough, 
this is a definite win.  Bytecode was first used, as far as I know, on 
machines with small memories -- about 64K RAM total or even less.

Byte-code can also be portable.  You just need to write a (usually 
amall) bytecode interpreter for each new machine.

Of course it's still possible to, at run-time, compile the most-used 
byte-coded functions in to actual machine code to trade memory use for 
execution time.

Answer 4:  An example:

The language FORTH used a *word*-code interpreter instead of a 
byte-code interpreter, each word being two bytes, and containing the 
address of the interpreter's machine-code routine that implemented that 
instruction.

This meant each word representing an instruction could be 
executed in the interpreter by a hardware function call to an 
indirect address.  In fact, user-coded functions could be called the 
same way -- each would be a sequence of addresses preceded by the 
machine code that invokes the word-code interpreter. 

Still very compact on a machine with two-byte addresses.

Utterly impractical on a modern machine with 64-bit addresses, where the 
machine code for an operation can often be smaller than a machine 
address.

-- hendrik 

I hope this set of answers clarifies the 

Re: [racket-users] Creating links to Racket docs for functions in user-scope packages

['Joel Dueck' via Racket Users]

On Friday, July 24, 2020 at 11:15:54 AM UTC-5 Matthew Flatt wrote:

> A solution might use something like `path->pkg+subpath+collect+scope`, 
> where a 'user result for the scope triggers a different path 
> calculation.


For my application, I was able to use this info to make a function that 
*seems* reliable for user-scope packages (at least, the ones I have tested 
with so far):

https://github.com/otherjoel/cookbook-pollen/compare/f5a07f237c...92bbd9d616

I will attempt something more robust (along the lines of your suggestion) 
for the pull request though.

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

Re: [racket-users] Does Racket interpreter exist?

[zeRusski]

This is a really cool piece of history! Thank you.

I'll admit I'm somewhat fuzzy here - it maybe a bit too meta for me or 
perhaps I don't quite understand what you're trying to say. Isn't 
interpreting n levels deep also linear in n? Only difference between the 
two approaches  I see is that compiler lets you persist the fruits of its 
labor so you don't have to start from scratch every time. Couldn't you 
accommodate this with an interpreter (with some effort) although at this 
point it becomes a compiler I suppose. Definitely fuzzy here.
 

> But when going n levels deep, the total execution time with a compiler 
> is linear in n, and with an interpreter it's exponential. 
>
> That makes interpreting interpreters impractical when n gets large (even 
> with n around 3 or 4); whereas compiling compilers can be done even for 
> larger n. 
>

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

[racket-users] Re: Quickscript competition ends Friday

[Stephen De Gabrielle]

Hi All, 

The example in the documentation is bad - it redefines 'reverse' (which is 
fine), then attempts to use it.

The working version changes the name of the script (which is just a 
function) to 'reverse-selection' so it doesn't cause the error:
 
(define-script 

 reverse-selection
  #:label "Reverse"
  (λ 

 (selection)
(list->string 

 (reverse 

 (string->list 

 selection)

I still think making scripts is easy and fun but I apologise for not 
testing the documentation.

here is a script I just made (and tested); 

#lang racket/base
;;; License: MIT/Apache2.0
(require browser/external
 quickscript)
(script-help-string "Racket Survey.")
(define-script racket-survey
  #:label "Racket Survey (browser)"
  #:menu-path ("")
  #:help-string "Complete the Racket Survey now"
  (λ (str) 
(send-url "https://forms.gle/XeHdgv8R7o2VjBbF9;)
#f))

click new script in the menu and give it a name 'survey' this will create a 
file 'survey.rkt' in the user scripts folder
paste in the above, save and click 'compile scripts and reload'. 
- you will find the script "Racket Survey (browser)" under 'News' in the 
scripts menu.

There is still time to enter and prizes to be won.
https://github.com/Quickscript-Competiton/July2020entries

Stephen


On Tuesday, July 28, 2020 at 4:59:26 PM UTC+1 Stephen De Gabrielle wrote:

> There are still prizes.
> It is easy and fun.
> Make DrRacket do what *you* want.
>
> Check it out: https://github.com/Quickscript-Competiton/July2020entries
>
> Stephen
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/66baaef5-6b7c-45cd-a399-818bac31d99en%40googlegroups.com.