Re: [racket-users] Searching in data the Racket way...

[Alex Knauth]

> On Oct 31, 2016, at 12:31 AM, Alex Harsanyi  wrote:
> 
> While in terms of O-notation, all linear algorithms are equivalent, the 
> actual time to run a linear algorithm can significantly depend on the actual 
> data structure.  In the program below, I calculate the sum of the elements of 
> a vector or list in three ways, all of them linear algorithms.
> 
> * calculating the sum of the elements in a list (do-time sum1 10) takes 296 
> milliseconds on my machine
> * calculating the sum of the elements in the vector, (do-time sum2 10) takes 
> 374 milliseconds (slower than the list version!)
> * calculating the sum of the elements in the vector by explicitly referencing 
> elements, (do-time sum3 10) takes 62 milliseconds.
> 
> I guess my example shows two things:
> 
> * the generator for vectors appears to have a performance problem (1.25 times 
> slower)
> * it is 4.7 times faster to iterate over vectors than it is to do it over 
> lists.
> 
> Best Regards,
> Alex.
> 
> #lang racket
> 
> (define nitems 100)
> (define as-list (for/list ([x (in-range nitems)]) (random nitems)))
> (define as-vector (list->vector as-list)) ; same data as in the list
> 
> (define (sum1)
>  (for/fold ((sum 0))
>((x as-list))

Try using (in-list as-list) here

>(+ sum x)))
> 
> (define (sum2)
>  (for/fold ((sum 0))
>((x as-vector))

and try (in-vector as-vector) here. That will take away some of the time taken 
by the generators.

>(+ sum x)))
> 
> (define (sum3)
>  (for/fold ((sum 0))
>((x (in-range (vector-length as-vector
>(+ sum (vector-ref as-vector x
> 
> (define (do-time fn (iterations 1))
>  (collect-garbage 'major)
>  (define start (current-inexact-milliseconds))
>  (for ((n (in-range iterations)))
>(fn))
>  (define end (current-inexact-milliseconds))
>  (- end start))

-- 
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] Searching in data the Racket way...

[Alex Harsanyi]

While in terms of O-notation, all linear algorithms are equivalent, the actual 
time to run a linear algorithm can significantly depend on the actual data 
structure.  In the program below, I calculate the sum of the elements of a 
vector or list in three ways, all of them linear algorithms.

* calculating the sum of the elements in a list (do-time sum1 10) takes 296 
milliseconds on my machine
* calculating the sum of the elements in the vector, (do-time sum2 10) takes 
374 milliseconds (slower than the list version!)
* calculating the sum of the elements in the vector by explicitly referencing 
elements, (do-time sum3 10) takes 62 milliseconds.

I guess my example shows two things:

* the generator for vectors appears to have a performance problem (1.25 times 
slower)
* it is 4.7 times faster to iterate over vectors than it is to do it over lists.

Best Regards,
Alex.

#lang racket

(define nitems 100)
(define as-list (for/list ([x (in-range nitems)]) (random nitems)))
(define as-vector (list->vector as-list)) ; same data as in the list
  
(define (sum1)
  (for/fold ((sum 0))
((x as-list))
(+ sum x)))

(define (sum2)
  (for/fold ((sum 0))
((x as-vector))
(+ sum x)))

(define (sum3)
  (for/fold ((sum 0))
((x (in-range (vector-length as-vector
(+ sum (vector-ref as-vector x

(define (do-time fn (iterations 1))
  (collect-garbage 'major)
  (define start (current-inexact-milliseconds))
  (for ((n (in-range iterations)))
(fn))
  (define end (current-inexact-milliseconds))
  (- end start))

-- 
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] handling terminal input per character

[Tony Garnock-Jones]

On 10/30/2016 10:54 AM, Ken MacKenzie wrote:
> So what is the best way to read keypress or character by character
> input in racket.  For now dealing with a CLI/terminal interface to
> keep it simple as I work to test and refine my methods.

Try the "ansi" package, https://pkgn.racket-lang.org/package/ansi.

This example shows reading of keys:
https://github.com/tonyg/racket-ansi/blob/master/ansi/test-raw.rkt

Cheers,
  Tony

-- 
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] handling terminal input per character

[Ken MacKenzie]

No this is reminding me that I need to think of my intended implementations and 
this is not a worth while thing to implement at the terminal level and also a 
case of prematurely attempting to optimize before dealing with the solution.

Intended implementation is I see a large part of this living on a server and 
clients communicating to it through json requests.  So that right there limits 
the usefulness of intercepting the key requests.

Also for heavier client side instances a possibility of implementing Sphinx for 
speech recognition is a goal and at that point we are dealing with something 
completely different.

Since the first part of the problem to solve is my ideas about Natural Language 
Processing I need to stop getting distracted from focusing on that problem 
which right now involves compiling a lot of data sets that I can quickly search 
through and the only performance optimizations I should really be dealing with 
at this stage is DB schema design for the linguistic data.

Ken

-- 
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] handling terminal input per character

['John Clements' via Racket Users]

> On Oct 30, 2016, at 07:54, Ken MacKenzie  wrote:
> 
> So a curiosity question.  Right now I am reading in a line of terminal input 
> from the user and handling it.  I am thinking of switching the program to 
> handle the input character by character, and just wondering how to do that 
> but also have it seem to the user that the program is waiting for them to 
> press enter, appear the same as a read-line basically.
> 
> The reason I want to do that is trigger some events for certain non-alpha for 
> now, white space and punctuation.  The other thing is eventually I may with 
> to begin some background processing as the user is completing the full input 
> string.  Basically the appearance of better performance using the bottle neck 
> of the time it takes a user to create the input.  Granted I will have to deal 
> with backspace or other cases where the user changes there mind.  Basically 
> doing some predictive text analysis sort of.
> 
> So what is the best way to read keypress or character by character input in 
> racket.  For now dealing with a CLI/terminal interface to keep it simple as I 
> work to test and refine my methods.

This is fundamentally not just a Racket question; for normal shell programs, 
the input buffering happens on the shell side, not on the Racket side. I 
believe this stack overflow answer may be of some use to you, or persuade you 
that it’s not worth it :).

http://stackoverflow.com/questions/4506704/how-to-disable-line-buffering-of-input-in-xterm-from-program#4506801

… actually, reading the comments there, it appears that the buffering doesn’t 
even happen in the shell directly: "The buffering does not take place in the 
terminal. It takes place in the kernel's tty driver.”

Apologies if you already knew all this, or if I’m wrong in some dramatic and 
fundamental way :).

John


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


signature.asc
Description: PGP signature

Re: [racket-users] handling terminal input per character

[Laurent]

Not too sure about your exact needs but:

- if you want to modify a shell terminal, hopefully someone else can help
you (maybe a keystroke can trigger a command that interacts with a racket
program running in the background?)

- if you want a Racket terminal (to evaluate Racket expressions) or just
some text terminal (say for a text adventure game), maybe you would be
better off making a GUI component if you can afford it, where you can
easily receive keystrokes and modify the text that the user inputs. Have a
look at GRacket for a GUI Racket terminal, otherwise a simple text% editor
should do it:
https://docs.racket-lang.org/gui/text_.html?q=gracket
Then you can derive a class from text% and implement the 'on-char' method
for example. This definitely has a larger implementation+doc-reading time
than a simple 'read-line', but once you've dealt with the boring GUI stuff,
it should be much simpler to do what you want with the user input,
including changing the currently selected text and navigating between
several text proposals with the arrow keys for example.

(
Also maybe have a look at open-input-text-editor:
https://docs.racket-lang.org/gui/Editor_Functions.html?q=gracket#%28def._%28%28lib._mred%2Fmain..rkt%29._open-input-text-editor%29%29
)

HTH,
Laurent

On Sun, Oct 30, 2016 at 2:54 PM, Ken MacKenzie  wrote:

> So a curiosity question.  Right now I am reading in a line of terminal
> input from the user and handling it.  I am thinking of switching the
> program to handle the input character by character, and just wondering how
> to do that but also have it seem to the user that the program is waiting
> for them to press enter, appear the same as a read-line basically.
>
> The reason I want to do that is trigger some events for certain non-alpha
> for now, white space and punctuation.  The other thing is eventually I may
> with to begin some background processing as the user is completing the full
> input string.  Basically the appearance of better performance using the
> bottle neck of the time it takes a user to create the input.  Granted I
> will have to deal with backspace or other cases where the user changes
> there mind.  Basically doing some predictive text analysis sort of.
>
> So what is the best way to read keypress or character by character input
> in racket.  For now dealing with a CLI/terminal interface to keep it simple
> as I work to test and refine my methods.
>
> Ken
>
> --
> 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] handling terminal input per character

[Ken MacKenzie]

So a curiosity question.  Right now I am reading in a line of terminal input 
from the user and handling it.  I am thinking of switching the program to 
handle the input character by character, and just wondering how to do that but 
also have it seem to the user that the program is waiting for them to press 
enter, appear the same as a read-line basically.

The reason I want to do that is trigger some events for certain non-alpha for 
now, white space and punctuation.  The other thing is eventually I may with to 
begin some background processing as the user is completing the full input 
string.  Basically the appearance of better performance using the bottle neck 
of the time it takes a user to create the input.  Granted I will have to deal 
with backspace or other cases where the user changes there mind.  Basically 
doing some predictive text analysis sort of.

So what is the best way to read keypress or character by character input in 
racket.  For now dealing with a CLI/terminal interface to keep it simple as I 
work to test and refine my methods.

Ken

-- 
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] Searching in data the Racket way...

[David Storrs]

Hi Meino,

I think there might be some confusion about how the word "linear" is being
used here, so let me step back.  Apologies if you already know this.

When talking about how long an algorithm takes, computer people tend to
talk in categories instead of in seconds or minutes. The categories refer
to the change in the algorithm's performance as the number of elements you
put in changes. For example, if it takes 1 second to run the algorithm on
10 elements and 10 seconds to run it on 100 elements then your algorithm
runs in "linear time" -- the graph of time taken vs elements seen is a
straight line.

The notation for this is O (pronounced "big oh") and "n" is the number of
elements sent into the algorithm.  You typically see the following
categories:


O(1), aka constant time. The time an O(1) algorithm takes does not
appreciably change as n increases.  Examples would be retrieval of a
randomly-chosen value from a hash, or an item from a vector -- essentially
you're just following a pointer so it doesn't matter how many items are in
the hash / vector.

O(n), aka linear time.  As stated above, the time increases directly as n
increases.  n = 10x takes 10x more time than n = x. Traversing a Racket
list is O(n), because you have to follow the links from one item to the
next instead of jumping straight to a destination the way you can for a
vector.  Important caveat:  retrieving the *next* item in a list is O(1),
since you're just following a pointer.

O(n*log(n)):  You see this with most sorting algorithms.  It's a little
slower than linear time, but not by much.

O(n^2), aka "n-squared":  This gets really slow, really fast, and is
something you definitely want to avoid.  It would typically mean you have
two nested loops, like this C-style example:
(for i = 0; i < n; i++){
(for j = 0; j < n; j++) {
 ...

What you said about following links in a list vs jumping straight to a
memory location is exactly right.  Because you can jump straight to a given
location in a vector, locating a randomly-selected item in a vector is
O(1), constant time.  Locating a randomly-selected item in a vector is
O(n), linear time, because you need to perform multiple "follow link"
operations to get there.  Remember the caveat, though:  locating the *next*
item is a list is O(1), because you're just following a pointer, the same
as doing a vector lookup.  That's key: it means that accessing all the
elements in a list is still O(n), as long as you do it in order.

And that brings us back to the big picture: the program you're talking
about  doesn't depend on the data structure.  If you need to look at n
elements, then your algorithm cannot possibly run in better than O(n) time
-- no matter how they are stored, looking at 100 elements will take 10x
more time than looking at 10 elements.

So both you and Matthias are correct, but you're talking about different
things -- accessing a randomly-chosen element in a vector (what you're
talking about) is O(1) vs the O(n) of accessing a randomly-chosen element
in a vector.  Matthias, on the other hand, is talking about the actual time
that your code will take to process all the items in your file, and that's
dependent on how many items it has to process.  You basically need to do
the following (pseudo-code):

for 1 to n:
retrieve next element
do something to it

Whether your 'retrieve next element' is modeled as a vector lookup or a
link traversal (and remember, both of those are O(1) operations), you're
going to do that operation 10x more often when you have 10x more items.
That means the code he gave you runs in linear time, O(n), despite the fact
that it's using lists instead of vectors.


Does that all make sense?

Dave

On Sunday, October 30, 2016,  wrote:

>
> Hi Matthias,
>
> thanks for your reply ! :)
>
> H...your are asking a newbie, what not linear in processing
> lists...h... ;)
>
> I read somewhere on the net, that - in opposite to vectors --
> processing lists is not linear. I /think/ (read: dont know for
> sure), that searching needs extra time to jump along the
> links of the list (linked list, isn't it?) to the next element,
> while searching a vector needs (internally) only adding an index to a
> base pointer to acces the next element.
>
> So accessing the 1000th element of a list needs 1000 times
> "jump via link" plus inspecting the 1000th element and doing the
> same with a vector needs accessing the addr=(base address)+ (999* item
> size)
> and inspecting the element.
> Therefore the processing time of an element of a vector does not
> depend on the position of the element itsself.
>
> WARNING! THIS IS BASED ON "C" KNOWLEDGE!
> MAY BE TOTALLY WRONG!
>
> The code to implement the search is (hopefully, fingers crossed...)
> not the problem...I simply dont know data type/construct to choose
> to make it a little faster...
>
> Cheers,
> Meino
>
>
> Matthias Felleisen  [16-10-30 12:28]:
> >
> > > On 

Re: [racket-users] Searching in data the Racket way...

[Meino . Cramer]

Hi Matthias,

thanks for your reply ! :)

H...your are asking a newbie, what not linear in processing
lists...h... ;)

I read somewhere on the net, that - in opposite to vectors --
processing lists is not linear. I /think/ (read: dont know for
sure), that searching needs extra time to jump along the
links of the list (linked list, isn't it?) to the next element,
while searching a vector needs (internally) only adding an index to a 
base pointer to acces the next element.

So accessing the 1000th element of a list needs 1000 times 
"jump via link" plus inspecting the 1000th element and doing the 
same with a vector needs accessing the addr=(base address)+ (999* item size)
and inspecting the element.
Therefore the processing time of an element of a vector does not
depend on the position of the element itsself.

WARNING! THIS IS BASED ON "C" KNOWLEDGE!
MAY BE TOTALLY WRONG!

The code to implement the search is (hopefully, fingers crossed...)
not the problem...I simply dont know data type/construct to choose
to make it a little faster...

Cheers,
Meino


Matthias Felleisen  [16-10-30 12:28]:
> 
> > On Oct 30, 2016, at 11:02 AM, meino.cra...@gmx.de wrote:
> > 
> > Hi,
> > 
> > (still fiddling around with those data of shortwave broadcasters and
> > their schedules...)
> > 
> > The data in question consists of 7400 lines of 16 fields each. Not all
> > fields are filled in eacht line. The already existing code reads the
> > data into lists of sublists of 16 fields/items.
> > 
> > I want to prepare those data in a way, that I will be able to do searches
> > like "give me all broadcaster, which broadcasts are in English.
> > Furthermore give me broadcasts on Thursdays only between 5:30
> > pm and 8:00 pm on bands between 9000Khz and 12000khz”.
> 
> This looks like a “one-liner” to me in Racket: 
> 
> (filter (lambda (r) (and (language-is r English) (broadcast-day-is Thursday) 
> (broadcast-time-is-between 5:30 8:00) (broadcast-frequencies-are-between 9000 
> 12000)) list-of-data)
> 
> What’s not linear about this? 
> 
> 
> — Matthias
> 
> 
> 
> > 
> 
> > For the learning effect I want to do this in racket onlu and (despite 
> > knowing that this may be a better solultion performance wise) dont
> > want to use tools like sqlite or such.
> > 
> > What I read/think is:
> > Lists processing is not linear: The longer the list, the slower the
> > data processing.
> > Hashes are somehow problematic due to the data:
> > There is no real unique key beside an artificial, additonally created
> > IDwhich is of no information to the user...
> > Vectors? Linear performance in opposite to lists...but searching
> > in a vector of vectors ,,, is that sane enough to be implementable? ;)
> > What else?
> > 
> > 
> > Cheers,
> > Meino
> > 
> > -- 
> > 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.

[racket-users] Re: Searching in data the Racket way...

[George Neuner]

On Sun, 30 Oct 2016 11:02:38 +0100,
meino.cra...@gmx.de wrote:

>The data in question consists of 7400 lines of 16 fields each. Not all
>fields are filled in eacht line. The already existing code reads the
>data into lists of sublists of 16 fields/items.
>
>I want to prepare those data in a way, that I will be able to do searches
>like "give me all broadcaster, which broadcasts are in English.
>Furthermore give me broadcasts on Thursdays only between 5:30
>pm and 8:00 pm on bands between 9000Khz and 12000khz".

To answer such questions efficiently, you need each data "record" to
be an O(1) data structure -  i.e.  a vector or a struct  - so that you
can access any "field" in constant time.

https://docs.racket-lang.org/reference/vectors.html?q=vectors#%28def._%28%28quote._~23~25kernel%29._vector%29%29
https://docs.racket-lang.org/reference/define-struct.html?q=struct#%28form._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._struct%29%29


>What I read/think is:
>Lists processing is not linear: The longer the list, the slower the
>data processing.

Racket is very efficient at processing lists.   Matthias's post
already hinted that the list of data "records" is not a problem.

But the "list of lists" is - at least potentially - a problem because
to answer your questions, you need to access arbitrary "fields" of the
"records".  

A 16 element list is relatively small, but with a larger "record", the
difference between O(n) and O(1) access to the "fields" could become
significant.

The main thing about lists is that you always want to process them in
order.  You don't want to use algorithms that need to access arbitrary
elements of the list, or that need to know the length of the list.


>Hashes are somehow problematic due to the data:
>There is no real unique key beside an artificial, additonally created
>IDwhich is of no information to the user...

For the built-in hashes, the key may be any object, including a list.
You also can define custom hash types..

https://docs.racket-lang.org/reference/define-struct.html?q=struct#%28form._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._struct%29%29
https://docs.racket-lang.org/reference/hashtables.html?q=hash#%28def._%28%28quote._~23~25kernel%29._hash%29%29
https://docs.racket-lang.org/reference/dicts.html?q=dictionary#%28tech._dictionary%29

The problem with using hashes in this case is that they really aren't
designed to answer arbitrary questions.  You'd need to create a
separate hash for every type of "search" you wanted to perform.


>Vectors? Linear performance in opposite to lists...but searching
>in a vector of vectors ,,, is that sane enough to be implementable? ;)
>What else?

There's no problem with vectors of vectors, but you don't need
anything like that here.


Keeping it simple, I would define a struct to represent your data
"records" and read in the file as a list of these structs.  Then write
little "search" functions to walk down the list, examining each struct
for fields that match your "query".

Hope this helps,
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] Searching in data the Racket way...

[Matthias Felleisen]

> On Oct 30, 2016, at 11:02 AM, meino.cra...@gmx.de wrote:
> 
> Hi,
> 
> (still fiddling around with those data of shortwave broadcasters and
> their schedules...)
> 
> The data in question consists of 7400 lines of 16 fields each. Not all
> fields are filled in eacht line. The already existing code reads the
> data into lists of sublists of 16 fields/items.
> 
> I want to prepare those data in a way, that I will be able to do searches
> like "give me all broadcaster, which broadcasts are in English.
> Furthermore give me broadcasts on Thursdays only between 5:30
> pm and 8:00 pm on bands between 9000Khz and 12000khz”.

This looks like a “one-liner” to me in Racket: 

(filter (lambda (r) (and (language-is r English) (broadcast-day-is Thursday) 
(broadcast-time-is-between 5:30 8:00) (broadcast-frequencies-are-between 9000 
12000)) list-of-data)

What’s not linear about this? 


— Matthias



> 

> For the learning effect I want to do this in racket onlu and (despite 
> knowing that this may be a better solultion performance wise) dont
> want to use tools like sqlite or such.
> 
> What I read/think is:
> Lists processing is not linear: The longer the list, the slower the
> data processing.
> Hashes are somehow problematic due to the data:
> There is no real unique key beside an artificial, additonally created
> IDwhich is of no information to the user...
> Vectors? Linear performance in opposite to lists...but searching
> in a vector of vectors ,,, is that sane enough to be implementable? ;)
> What else?
> 
> 
> Cheers,
> Meino
> 
> -- 
> 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] 6.7.0.2: DYLD, [0x1] Library missing (macOS 10.12)

[Matthew Flatt]

Snapshot builds are not yet signed, so Sierra doesn't like them. (We'll
eventually change the snapshot builds to provided signed disk images,
like the ones for the normal release.)

To work around the problem:

 * Drag the DrRacket application out of its enclosing folder.

   You may need to hold down the Command key while dragging to move the
   application instead of creating an alias. I think that especially
   applies if you've put the folder in "Applications".

 * Move the DrRacket application back wher eit was.

While simply moving the application around may sound strange, Sierra
treats that as an indication to not apply a form of sandboxing to the
application.

Even after those steps, you may need to control-click to start the
application the first time (as you've done before, I assume).


At Sat, 29 Oct 2016 00:48:07 -0700 (PDT), ylluminate wrote:
> Anyone see this on the snapshot builds yet when you try to execute DrRacket?
> 
> Process:   DrRacket [47564]
> Path:  /Volumes/VOLUME/*/DrRacket.app/Contents/MacOS/DrRacket
> Identifier:org.racket-lang.DrRacket
> Version:   6.7.0.2 (6.7.0.2)
> Code Type: X86-64 (Native)
> Parent Process:??? [1]
> Responsible:   DrRacket [47564]
> User ID:   501
> 
> Date/Time: 2016-10-29 03:45:47.090 -0400
> OS Version:Mac OS X 10.12 (16A323)
> Report Version:12
> Anonymous UUID:C922F17F-2738-E434-EFFD-92FD7558E87E
> 
> 
> Time Awake Since Boot: 38 seconds
> 
> System Integrity Protection: disabled
> 
> Crashed Thread:0
> 
> Exception Type:EXC_CRASH (SIGABRT)
> Exception Codes:   0x, 0x
> Exception Note:EXC_CORPSE_NOTIFY
> 
> Termination Reason:DYLD, [0x1] Library missing
> 
> Application Specific Information:
> dyld: launch, loading dependent libraries
> 
> Dyld Error Message:
>   Library not loaded: 
> @executable_path/../../../lib/Racket.framework/Versions/6.7.0.2_3m/Racket
>   Referenced from: /Volumes/VOLUME/*/DrRacket.app/Contents/MacOS/DrRacket
>   Reason: image not found
> 
> Binary Images:
>0x10af3b000 -0x10af43ff7 +org.racket-lang.DrRacket (6.7.0.2 - 
> 6.7.0.2) <89A5AB8A-5352-3D66-94F2-A5A902B0137F> 
> /var/folders/*/DrRacket.app/Contents/MacOS/DrRacket
>0x10e96c000 -0x10e9a91c7  dyld (421.1) 
>  /usr/lib/dyld
> 
> -- 
> 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] Searching in data the Racket way...

[Meino . Cramer]

Hi,

(still fiddling around with those data of shortwave broadcasters and
their schedules...)

The data in question consists of 7400 lines of 16 fields each. Not all
fields are filled in eacht line. The already existing code reads the
data into lists of sublists of 16 fields/items.

I want to prepare those data in a way, that I will be able to do searches
like "give me all broadcaster, which broadcasts are in English.
Furthermore give me broadcasts on Thursdays only between 5:30
pm and 8:00 pm on bands between 9000Khz and 12000khz".

For the learning effect I want to do this in racket onlu and (despite 
knowing that this may be a better solultion performance wise) dont
want to use tools like sqlite or such.

What I read/think is:
Lists processing is not linear: The longer the list, the slower the
data processing.
Hashes are somehow problematic due to the data:
There is no real unique key beside an artificial, additonally created
IDwhich is of no information to the user...
Vectors? Linear performance in opposite to lists...but searching
in a vector of vectors ,,, is that sane enough to be implementable? ;)
What else?


Cheers,
Meino

-- 
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: Print...a newbies problem ;)

[Meino . Cramer]

Hi Georgs,

thanks for your reply! :)

NICE!

Even here, in the non-imperative, functional world, "C" leaves
its footprints in the snow... :

Cheers,
Meino



George Neuner  [16-10-30 10:08]:
> On Sat, 29 Oct 2016 13:45:43 +0200,
> meino.cra...@gmx.de wrote:
> 
> >currently I am still doing old-school "printf()-debugging", knowing
> >that it's '(print arg)' rather than 'printf( fmt, val,...);". :)
> 
> Just FYI:  Racket does have printf, fprintf and eprintf.  
> The format strings are a little different from those in C.
> 
> See  https://docs.racket-lang.org/reference/Writing.html
> 
> 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.
> 

-- 
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: cvs-reading ?

[Alexis King]

This appears to be an issue with the comments on the first three lines
interfering with the shebang line. Don’t include them, they’re only in
the docs for illustrative purposes. In the meantime, I’ll update the
documentation to remove that issue with the example.

> On Oct 29, 2016, at 22:31, meino.cra...@gmx.de wrote:
> 
> 
> Hi Jack,
> 
> thanks fpr your reply ! :)
> 
> I tried that with this script (copied from the docs, "/bin/env racket
> replace by the actually path to racket):
> 
>#!/usr/local/bin/racket; \
>#lang scripty  ; | script preamble
>#:dependencies '("cvs-reading"); /
>--
>#lang racket
> 
>(require cvs-reading)
> 
> and it failed with:
> 
>default-load-handler: cannot open module file
>module path: #
>path: /home/mccramer/; \
>system error: No such file or directory; errno=2
>context...:
>standard-module-name-resolver
>[1]32658 exit 1 ./test.rkt
> 
> What did I wrong here?
> 
> Cheers
> Meino

-- 
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: Print...a newbies problem ;)

[George Neuner]

On Sat, 29 Oct 2016 13:45:43 +0200,
meino.cra...@gmx.de wrote:

>currently I am still doing old-school "printf()-debugging", knowing
>that it's '(print arg)' rather than 'printf( fmt, val,...);". :)

Just FYI:  Racket does have printf, fprintf and eprintf.  
The format strings are a little different from those in C.

See  https://docs.racket-lang.org/reference/Writing.html

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] Print...a newbies problem ;)

[Meino . Cramer]

Hi Matthew,

thanks for your reply ! :)

The problem was: That print loop creates a lot of #\spaces before
dumping the 7000+ of data lines. And there was no #\n between the
lines.

In vim I saw "nothing" (not exspecting that there were valid
data after those spaces).
On the console this block of spaces were ast scrolled out of sight
and the valid data were shown.

And I thought, dumping into vim does something different than dumping
to the console.

I didn't know of log-error before...thanks for that info ! :)

Cheers
Meino



Matthew Flatt  [16-10-30 08:36]:
> Probably you need to use `flush-output` to make sure that your printed
> output is sent to the pipe.
> 
> When stdout goes to a terminal, the default buffer mode is
> line-buffered, so that printing a newline causes output to be flushed.
> For any other output destination, including a pipe to another process,
> the default buffer mode is block-buffered, so that output will not be
> flushed until the buffer is full.
> 
> Another approach is to write to stderr instead of stdout, since stderr
> is never buffered by default.
> 
> I normally use `log-error` instead of printf. The output goes to stderr
> when I run on the command line, but it adapts better to other
> environments, such as running in DrRacket (where it goes to the log
> window).
> 
> At Sat, 29 Oct 2016 13:45:43 +0200, meino.cra...@gmx.de wrote:
> > Hi,
> > 
> > currently I am still doing old-school "printf()-debugging", knowing
> > that it's '(print arg)' rather than 'printf( fmt, val,...);". :)
> > 
> > Since my program reads a bigger textfile of shortwave broadcasters,
> > their frequencies, on-air times, etc, reformats the whole thing
> > and (currently only to proof, everything is correct) prints it.
> > 
> > Since I need to now, where strings are starting and ending, I am using
> > 'print' for that rather than 'pretty-print' or 'display'.
> > 
> > I am doing all this on UNIX/Linux.
> > 
> > To give myself a chance of reading the output I do this
> > 
> > racket shwrefmt.rkt | vim -
> > 
> > which reads everything, which goes to stdout into vim.
> > 
> > As long as I am using 'display', everything is fine.
> > When using 'print' the output mutates to smoke and vanishes in the pipe -
> > Vim starts with nothing to show.
> > 'print'ing to the console works fine, though.
> > 
> > Giving at the REPL
> > > (current-output-port)
> > it says
> > #
> > 
> > which looks like the good-old STDOUT of UNIX to me...
> > 
> > Where is the output gone? <>
> > 
> > Thanks a lot for any help in advance!
> > Cheers,
> > Meino
> > 
> > 
> > 
> > 
> > 
> > -- 
> > 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] Print...a newbies problem ;)

[Matthew Flatt]

Probably you need to use `flush-output` to make sure that your printed
output is sent to the pipe.

When stdout goes to a terminal, the default buffer mode is
line-buffered, so that printing a newline causes output to be flushed.
For any other output destination, including a pipe to another process,
the default buffer mode is block-buffered, so that output will not be
flushed until the buffer is full.

Another approach is to write to stderr instead of stdout, since stderr
is never buffered by default.

I normally use `log-error` instead of printf. The output goes to stderr
when I run on the command line, but it adapts better to other
environments, such as running in DrRacket (where it goes to the log
window).

At Sat, 29 Oct 2016 13:45:43 +0200, meino.cra...@gmx.de wrote:
> Hi,
> 
> currently I am still doing old-school "printf()-debugging", knowing
> that it's '(print arg)' rather than 'printf( fmt, val,...);". :)
> 
> Since my program reads a bigger textfile of shortwave broadcasters,
> their frequencies, on-air times, etc, reformats the whole thing
> and (currently only to proof, everything is correct) prints it.
> 
> Since I need to now, where strings are starting and ending, I am using
> 'print' for that rather than 'pretty-print' or 'display'.
> 
> I am doing all this on UNIX/Linux.
> 
> To give myself a chance of reading the output I do this
> 
> racket shwrefmt.rkt | vim -
> 
> which reads everything, which goes to stdout into vim.
> 
> As long as I am using 'display', everything is fine.
> When using 'print' the output mutates to smoke and vanishes in the pipe -
> Vim starts with nothing to show.
> 'print'ing to the console works fine, though.
> 
> Giving at the REPL
> > (current-output-port)
> it says
> #
> 
> which looks like the good-old STDOUT of UNIX to me...
> 
> Where is the output gone? <>
> 
> Thanks a lot for any help in advance!
> Cheers,
> Meino
> 
> 
> 
> 
> 
> -- 
> 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] cvs-reading ?

[Meino . Cramer]

Hi John,

thanks for your reply! :)

the only cause for makeing my life "terrible" at that moment
was myself and the lack of coffee
I confused csv with cvs
No need to apologize for anything, John!!!
I am the only person, who needs to apologize...you understand
everything correctly...

Only at work autocorrection is makeing my life terrible...in
that moments I want my Linux back... :)

Cheers
Meino



'John Clements' via Racket Users  [16-10-30 
07:08]:
> 
> > On Oct 29, 2016, at 22:35, meino.cra...@gmx.de wrote:
> > 
> > 
> > Hi John,
> > 
> > 
> > from my racket 6.6 installation ($HOME):
> > 
> > :user/.racket>l
> > total 20
> > drwxr-xr-x 5 user users 4096 2016-10-21 05:25 6.6
> > drwxr-xr-x 5 user users 4096 2016-10-30 06:21 6.7
> > drwxr-xr-x 2 user users 4096 2016-10-30 06:21 download-cache
> > -rw-r--r-- 1 user users 5254 2016-10-30 06:25 racket-prefs.rktd
> > :user/.racket>cd 6.6
> > :.racket/6.6>l
> > total 16
> > drwxr-xr-x 5 user users 4096 2016-10-21 05:26 doc
> > -rw-r--r-- 1 user users   91 2016-10-21 05:25 links.rktd
> > drwxr-xr-x 5 user users 4096 2016-10-21 05:25 pkgs
> > drwxr-xr-x 2 user users 4096 2016-10-21 05:25 share
> > :.racket/6.6>cd pkgs
> > :6.6/pkgs>l
> > total 16
> > drwxr-xr-x 4 user users 4096 2016-10-21 05:25 csv-reading
> > drwxr-xr-x 4 user users 4096 2016-10-21 05:25 mcfly
> > drwxr-xr-x 4 user users 4096 2016-10-21 05:25 overeasy
> > -rw-r--r-- 1 user users  373 2016-10-21 05:25 pkgs.rktd
> > :6.6/pkgs>
> > 
> > so I thought, that there must be a cvs-reading-pkg in 6.7
> > too…
> 
> hang on, look closely:
> 
> CSV-reading
> vs
> CVS-reading
> 
> not the same.
> 
> There is a csv-reading package. There is not a cvs-reading package.
> 
> Right?
> 
> Apologies if I’m misunderstanding you somehow. Or if auto-correct is making 
> your life terrible :).
> 
> John Clements
> 
> 
> -- 
> 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] cvs-reading ?

['John Clements' via Racket Users]

> On Oct 29, 2016, at 22:35, meino.cra...@gmx.de wrote:
> 
> 
> Hi John,
> 
> 
> from my racket 6.6 installation ($HOME):
> 
> :user/.racket>l
> total 20
> drwxr-xr-x 5 user users 4096 2016-10-21 05:25 6.6
> drwxr-xr-x 5 user users 4096 2016-10-30 06:21 6.7
> drwxr-xr-x 2 user users 4096 2016-10-30 06:21 download-cache
> -rw-r--r-- 1 user users 5254 2016-10-30 06:25 racket-prefs.rktd
> :user/.racket>cd 6.6
> :.racket/6.6>l
> total 16
> drwxr-xr-x 5 user users 4096 2016-10-21 05:26 doc
> -rw-r--r-- 1 user users   91 2016-10-21 05:25 links.rktd
> drwxr-xr-x 5 user users 4096 2016-10-21 05:25 pkgs
> drwxr-xr-x 2 user users 4096 2016-10-21 05:25 share
> :.racket/6.6>cd pkgs
> :6.6/pkgs>l
> total 16
> drwxr-xr-x 4 user users 4096 2016-10-21 05:25 csv-reading
> drwxr-xr-x 4 user users 4096 2016-10-21 05:25 mcfly
> drwxr-xr-x 4 user users 4096 2016-10-21 05:25 overeasy
> -rw-r--r-- 1 user users  373 2016-10-21 05:25 pkgs.rktd
> :6.6/pkgs>
> 
> so I thought, that there must be a cvs-reading-pkg in 6.7
> too…

hang on, look closely:

CSV-reading
vs
CVS-reading

not the same.

There is a csv-reading package. There is not a cvs-reading package.

Right?

Apologies if I’m misunderstanding you somehow. Or if auto-correct is making 
your life terrible :).

John Clements


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


signature.asc
Description: PGP signature