Re: [racket-users] high memory usage of gui app

[Michael Titke]

I have written a little card game Open Flowers which needed about the 
same amount of memory.


My guess is that amount of memory is just the "fuel memory" the engine 
needs from one garbage collection cycle to the next. Traditional 
mark stop-the-world garbage collection seems to come to an end 
nowadays as far as the performance of modern applications is concerned. 
The faster the machine the more memory it needs between the cycles - the 
more memory the application uses the longer it takes to mark ...


On 07/09/2015 22:01, Martin DeMello wrote:
I have a small GUI app that is taking up a lot of memory - 135MB even 
when run from a compiled executable and 235MB when run via "racket 
gui.rkt". Is this expected? If not, could someone please take a quick 
look and see if I'm doing something obviously wrong?


Code is here: 
https://github.com/martindemello/pangrid/tree/polyglot/racket


martin
--
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] help on coding finite state automata

[Michael Titke]

On 03/09/2015 16:29, Linh Chi Nguyen wrote:

Dear All,
I'm a complete newbie in racket and need help in coding finite state 
machine/automata. Please pardon any of my ignorance.

Thanks to this post of Tim Thornton, I see a very good way to code FSM:
http://timthornton.net/blog/id/538fa6f2f09a16ba0674813d


Looks interesting! When I first heard of finite state machines they were 
presented to me as an abstract model
of computers in general. AFAIR finite state automatons are used to teach 
how to realize really fast orthography checks but for me these were more 
connected to the concept of directed cyclic graphs.




HERE IS THE QUESTION:


Using this way, after each event, there'd be a NEW automaton created.


That's because of pure functional programming as the post states.



So I'm worried about scaling. I'd like to generate 100 automata. In each cycle, 
I'd pair the automata to interact for 50 times. Which means that there'd be 100 
new automata created for every single cycle. And I'd like to run at least 1000 
cycles.

Would there be any problem with scaling? If yes, is there a way around this?


With the knowledge of a regular computer already being such an automaton 
(in some way) I have learned
to appreciate the /case/ form for data driven programming. Especially if 
one doesn't care about past states (which will need memory one way or 
the other) it's probably better to describe the automaton "from inside" 
and see the whole program (or some part of it) as an automaton. For 
event driven programs nowadays (at least in Racket) we only need to 
define the actions as regular procedures or callbacks.


--
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] FrTime basics

[Michael Titke]

Last time I checked FrTime (and Reactive Programming in general) it 
seemed to me like a specialized application of constrained based 
programming. There is a run-time part and while some applications of the 
concept in other programming languages (such as C#) offer only some 
syntactic forms to go reactive FrTime is based on such a run time 
system. As far as I remember its forms are deliberately designed to look 
like regular Racket forms but they are interpreted by the run time. 
Nonetheless it somehow felt like a prove of concept. The last focus of 
development regarding reactive programming I found was some Google 
hosted application implemented with JavaScript? More I don't know (or 
remember) as I then left off to explore other grounds of the Racket 
world which I only entered through FrTime.


On 13/08/2015 12:55, Aidan Gauland wrote:

Are there any non-graphical FrTime demos?  I'm trying to figure out how
to define your own behaviors, and just going by the manual
http://docs.racket-lang.org/frtime/, it seems rather imperative in
nature, which is not what I understood it to be from reading the
whitepaper.
https://cs.brown.edu/people/sk/Publications/Papers/Published/ck-frtime/paper.pdf

I see that the definition of 'seconds' is using set-signal-thunk! and
set-signal-value!, which are not exported by the library (in other
words, not part of the language).

Have I completely misunderstood how FrTime is meant to be used?  Have I
hit its limitations, still being in the early states?  Or have I simply
been tripped up by gaps in the documentation?

Regards,
Aidan Gauland



--
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] is this a bug?

[Michael Titke]

On 07/08/2015 22:43, Alexander D. Knauth wrote:

On Aug 7, 2015, at 12:27 PM, Michael Titke michael.tied...@o2online.de wrote:


I always suspected this to be a logical joke of forcing people to write their 
own quantifiers and to not let them fall for predicate logic.

The best thing about a logic scheme declaring everything but really everything 
to be true when it is not false are expressions like the following:
(when (cond (#f 'true)) 'what-is-true?) = 'what-is-true?

The confusing thing about your example, I think, is that cond returns #void 
if none of the clauses match, when it would be slightly less bug-prone if it raised 
an error in that case.


Right!




Yes, even unspecified is not false but it could have been. But that was not 
specified. ;-)

Do you mean #void?  I think it's great that #void is a truthy value, 
because it allows things like:


Yes, I meant #void. That's even better then /unspecified/ even if it 
doesn't alway capture the concept.





(and
   (some-predicate ...)
   (some-effect-returning-void ...)
   (some-predicate ...)
   (some-effect-returning-void ...)
   ...)

Or possibly one of those effects could return void on success, but false on a 
failure, which would cause the `and` expression to stop and return false, 
signaling a failure. That's one nice use of that, at least.


As a matter of style I prefer the form /(and predicate1 ... predicate-n 
side-effect)/ or I know about the return values of a row of side-effects.



Also the simpler the true/false separation is, the better, in my opinion.
Additionally it's a good idea to keep it on a level where you can 
distinguish it from error reporting.


--
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: is this a bug?

[Michael Titke]

These procedure were necessary to represent questions like IS THERE ANY 
stack on the table onto which I could put this card?, Is the top card 
of ALL foundations a king?. If so then you have won! :-)


I think they call these quantifiers and these tend to be used as 
descriptive ones, prescriptive ones and even as predicates in formal 
logic. Top-down A and Right-to-Left E, right? I'm not able to find the 
code points for these symbols right now ...


On 07/08/2015 22:48, sagyo12341...@gmail.com wrote:

Dear crafty schemer, Micheal

Perhaps may you mistake quantifier and identifier?

I don't know about lisp, at least in C, we call the [a-zA-Z][0-9a-zA-Z]* identifier. And in general, 
quantifier is any and exists in math.



--
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] is this a bug?

[Michael Titke]

I always suspected this to be a logical joke of forcing people to write 
their own quantifiers and to not let them fall for predicate logic.


The best thing about a logic scheme declaring everything but really 
everything to be true when it is not false are expressions like the 
following:

(when (cond (#f 'true)) 'what-is-true?) = 'what-is-true?

Yes, even unspecified is not false but it could have been. But that was 
not specified. ;-)



On 06/08/2015 17:55, Matthias Felleisen wrote:

No, it's syntax.

On Aug 6, 2015, at 11:09 AM, sagyo12341...@gmail.com wrote:


In racket, the proc apply-or is needed.


(or #f 1 2 #f 3 4 #f)

1

(apply or (list #f 1 2 #f 3 4 #f))

. or: bad syntax in: or

(define (apply-or lst) (foldr or #t lst))

. or: bad syntax in: or

(define (apply-or lst) (foldr (lambda (x y) (or x y)) #t lst))
(apply-or (list #f 1 2 #f 3 4 #t))

1

(foldl (lambda (x y) (or x y)) #t (list #f 1 2 #t 3 4 #t))

#t

--
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] eval PSA (was Sending Closures to Places)

[Michael Titke]

On 04/08/2015 16:34, Alexis King wrote:


And that, I think, is the problem: eval seems a lot like a “one size fits all” 
approach to problem solving.
...
We write in high-level languages for a reason. There’s no reason to stunt their 
ability to abstract by directly calling eval.



I do understand that attitude of staying on top of a platform and in the 
high levels of a high level language. Exactly for those reasons some 
have written that pityful subroutine called eval and others even 
maintain it from time to time - just to not get your feets wet ;-) if 
not for a very good reason.


--
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] eval PSA (was Sending Closures to Places)

[Michael Titke]

I don't know why but at some point in the 20th century people really 
became afraid of viewing programs as pure data (which they are) and 
started to call it metacircular (which of course also refers to other 
properties of a list processor treating each and every start of list, 
i.e. opening parenthese, as an apply instruction).


One the one hand I reject any security concerns about /eval /which is as 
good or bad as input data as are the key codes from your favorite event 
handling loop determining your programs actions. A simple /(send object 
message arguments)/ could be implemented by evaluating /message/ in the 
environment of /object/, i.e. applying it to the /arguments/. The use of 
/eval/ shouldn't be restricted to proclaimed  designers of algorithmic 
notations but using it correctly needs some understanding of Scheme and 
its specifications. That necessary knowledge used to be conveyed in a 
lecture of one semester at the MIT with SICP (I've read).


But then /eval/ would need behave as expected and respect its current 
environment aka lexical scope. Maybe Racket does this right but a lot of 
Scheme implementation show their true nature when it comes to /eval/ and 
lexical scope: they revert back to Lisp mode and evaluate the forms in 
the top level environment. This unexpected behavior might explain why 
some people still feel uncomfortable with /eval./


As a matter of style one should use /eval/ where it means what it is 
good for: evaluating (sub) programs. Contrary to some advertisement 
material /eval/ doesn't really support sand boxing as it is only 
possible to restrict the name space of the evaluation but not the 
computing resources needed. Maybe you want to read in that SGML data as 
s-expression and evaluate it in the HTML environment - but maybe it 
would be better to traverse the data graph with your own algorithms ...


On 03/08/2015 13:32, Josh Grams wrote:

On 2015-08-03 01:22AM, Neil Van Dyke wrote:

Eval might indeed be the perfect solution this time, iff every other
conceivable alternative has been rejected. :)

Shameless link to PSA on the topic of eval:
http://lists.racket-lang.org/users/archive/2014-July/063597.html

Suggestions for other forms for PSA are welcome:

If people knew *why* and *how* to avoid eval, wouldn't they already be
doing it? To be useful to your target audience, I think you *need* to
back this up with a link to supporting documentation. I'd be looking
for:

- A *brief* high-level statement of why eval causes problems: maybe
   something like this? I'm sure there are better statements out there...

   eval takes code which was constructed in one context and assigns
   meaning to it in a different context. This can cause the code to have
   an unexpected meaning, or fail to work altogether. It can also cause
   security problems (if you pass it code from an untrusted source) or be
   unnecessarily slow (evaluating code at runtime which could have been
   fixed at compile time).

- Rules of thumb for how to decide what to use instead, and when eval
   might be ok. This answer (http://stackoverflow.com/a/2571549/2426692)
   suggests asking:
   
   - Do I really need eval or does the compiler/evaluator already do what

I want?
   - Does the code really need to be constructed at runtime or can it be
constructed earlier?
   - Will funcall, reduce, or apply work instead?

- Concrete examples of where beginners tend to use eval and how to code
   them without it. This is sort of the same as the previous one, but I
   like to see a short overview of the whole strategy by itself, so I
   would put the examples separately, e.g. HTDP has a *nice* clear
   overview of the design recipe, whereas HTDP 2e has no place where you
   can go for a quick refresher of what were the steps of the design
   recipe again?

-

That's my two cents. I always see these sorts of things getting brushed
off as unhelpful or even patronizing, so I think you want to go out of
your way to make it easy to dig into it and reach successively deeper
levels of understanding.

--Josh



--
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] Sending Closures to Places

[Michael Titke]

On 03/08/2015 07:22, Neil Van Dyke wrote:

Michael Titke wrote on 08/03/2015 12:50 AM:


Perhaps /quote/ and /eval/ would do the job? That is the usual way to 
treat Scheme code as data and data as Scheme code.


Eval might indeed be the perfect solution this time, iff every other 
conceivable alternative has been rejected. :)


Shameless link to PSA on the topic of eval: 
http://lists.racket-lang.org/users/archive/2014-July/063597.html


Suggestions for other forms for PSA are welcome: 
http://lists.racket-lang.org/users/archive/2014-July/063618.html


Neil V.

On a second thought you would even need to serialize the data graph 
(let's just call it string) and unstring it on the other side with the 
infamous /read/. You could just send a dot rkt file there ...


--
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] Sending Closures to Places

[Michael Titke]

On 02/08/2015 19:12, Konstantin Weitz wrote:

I'm trying to write a distributed racket program using [places][0]. From my 
current understanding, this means that I have to send data to each place over a 
channel using the `place-channel-put` function, which can send any value 
accepted by `place-message-allowed?`.

I would like to send closures over a channel, unfortunately, closures are not 
accepted by `place-message-allowed?`. Is there any way to serialize a closure 
into a value accepted by a channel, and then deserialize it on the other side 
of the channel?

The closures that I'm trying to send are side-effect free. The closures are 
defined using `lambda`.

[0]: http://docs.racket-lang.org/reference/places.html



Perhaps /quote/ and /eval/ would do the job? That is the usual way to 
treat Scheme code as data and data as Scheme code. But I don't know if 
there isn't a better way for already defined closures. You'll probably 
need to /quote/ the lambda form to get the data graph of the code before 
sending it to the other place to evaluate it. But then you're not 
sending the closure but only its form and binding of variables will take 
place in the other /place/.


--
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: is this a bug?

[Michael Titke]

On 01/08/2015 18:29, Ian Tegebo wrote:

On Wednesday, July 29, 2015 at 8:17:06 AM UTC-7, Michael Titke wrote:

 (define (apply-or well-formed-list)

   (foldl {lambda (a b) (or a b)}

  #f

  well-formed-list))

 (define (apply-and well-formed-list)

   (foldl {lambda (a b) (and a b)}

  #t

  well-formed-list))

 


 These aren't intelligent quantors but you'll see what their good
 for.

intelligent quantors?  Searching for that phrase only revealed this post.  Is 
it slang for something else?

It was meant to be a joke but english is a secondary language for me. I 
wanted to refer to is called QUANTIFIERS in english (not quantor as in 
german). Sorry for that one.

https://en.wikipedia.org/wiki/Quantifier_%28logic%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] Re: is this a bug?

[Michael Titke]

In the forgotten theory /fold/ should reduce its arguments like in the 
following examples:


(define (apply-or well-formed-list)
  (foldl {lambda (a b) (or a b)}
 #f
 well-formed-list))
(define (apply-and well-formed-list)
  (foldl {lambda (a b) (and a b)}
 #t
 well-formed-list))

These aren't intelligent quantors but you'll see what their good for.

I don't know why people try to find out about the inner workings of some 
implementation of an abstract operation by using it for things it wasn't 
meant for. Perhaps it's bad examples in some documentation. Perhaps my 
mind has just passed to much time in some other interpreter. ;-)


On 29/07/2015 16:46, sagyo12341...@gmail.com wrote:

You are right.

; proc, init and lst are from the racket reference.

(define (my-foldl proc init lst)
   (define (rec res rest1)
 (if (null? rest1)
 res
 (rec (proc res (first rest1)) (rest rest1
   (rec init lst))


(my-foldl (lambda (x y) (list x y)) '() '(a1 a2 a3 a4 a5))

'(() a1) a2) a3) a4) a5)



--
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] Correction: Half-life was *not* written in a Lisp after all.

[Michael Titke]

On 25/07/2015 14:02, Hendrik Boom wrote:

On Sat, Jul 25, 2015 at 12:04:07AM +, John Carmack wrote:

Half-life was written in C on my Quake 1 codebase.

Thank you for the correction.  Now I get to wonder what the truth
behind the rumour was.  Evidently not half-life.

-- hendrik



There is some open source game with a really gentle license and the 
wonderful name of Abuse.
It contains a Lisp interpreter game engine, level editor and some hidden 
great artwork. But it's only
2d parallax scrolling not real 3d. Wanna recreate Mario Bros? Go for 
it - all those cute little pixel

grafix are still there ...

--
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] garbage collection

[Michael Titke]

Some high water mark on the stack might be another improvement - it 
would only need to scan above it for changes - but on a second thought: 
that wouldn't work or change wouldn't mean anything anymore because of 
the Lazy Sweep.


Have you ever seen such a thing segfault after exactly 9000 cells and 
exactly 16 vectors. That was way too much C code fore me today ...


Usually you don't say they leak - they conserve. Sounds much better, 
right? It's just the same.


On 05/07/2015 20:36, Yuhao Dong wrote:
One thing to note, though, is that collectors like Boehm do support 
marking regions of memory as not containing pointers. IIRC, Boehm is 
actually quite performant, ignoring the fact that it might leak (and 
usually leaks for functional languages) - it's generational and 
incremental. The Unity game engine actually uses it (it uses an old 
version of Mono, which can only use Boehm)


 Date: Sun, 5 Jul 2015 07:38:48 +0200
 From: michael.tied...@o2online.de
 To: racket-users@googlegroups.com
 Subject: Re: [racket-users] garbage collection

 It's better to think about the malloc/gc duo as a memory manager. Some
 traditional approaches just seem awfully dumb and wrong like
 conservative marksweep. Treating every byte word on each and every 
call

 stack (every thread has one) as a valid reference to a Scheme object
 just doesn't scale well.
--
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 
mailto: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] garbage collection

[Michael Titke]

On 05/07/2015 01:00, Neil Van Dyke wrote:

Matthew Flatt wrote on 07/04/2015 06:40 PM:
That is, unlike so many other things in our infrastructure, the GC is 
not so tangled with everything else that it would be difficult to 
change by itself. Granted,


Good about GC not so tangled.

I don't know the current state of GC research, nor what GC ideas 
PLTers could come up with, but maybe there is a doctoral dissertation, 
or at least some MS projects, waiting to happen.


Separate from research activity, anyone know of existing off-the-shelf 
GCs that would be interesting to hook up to Racket?


There is the Memory Pool System Kit Readme (but I didn't have any time 
to test it yet): https://www.ravenbrook.com/project/mps/
(Perhaps SCM or even hobbit has a better GC: 
http://people.csail.mit.edu/jaffer/SCM)


It's better to think about the malloc/gc duo as a memory manager. Some 
traditional approaches just seem awfully dumb and wrong like 
conservative marksweep. Treating every byte word on each and every call 
stack (every thread has one) as a valid reference to a Scheme object 
just doesn't scale well.
 But computers are dumb machines anyway - fortunately they had a 
working power on/off switch back in those days when ... (nowadays you 
have to kill these beasts three times: pull the plug, remove the battery 
and wait at least 15 times n seconds for capacitors to ...)





GC implementation can be fairly challenging on its own.


Systems programming is hard, as you know. :)

Neil V.



That depends on the presence of the system manual and a good mental 
scheme of what one wants to achieve. I'd just start out with a flat 
addressing scheme implemented as one huge Scheme vector called 
RAM-emulation and try some algorithms in Scheme on it. Then segmentation 
and alignment and C pointers have never been the truth ...


--
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] Emacs Lisp as a Racket Language?

[Michael Titke]

On 02/07/2015 21:36, Greg Davidson wrote:

Is there interest in creating a Gnu Emacs Lisp Racket Language, along with the 
underlying APIs (perhaps tied to DrRacket) sufficient to compile and run Gnu 
Emacs Lisp extension packages?  Is there prior or ongoing work for such a 
project?

For some years there has been an attempt to port Gnu Emacs to run under Guile 
Scheme.  A big stumbling block is the vast amount of extensions written in 
Emacs Lisp and continuing development thereof.  Racket seems to be a *much* 
better platform for such a project than Guile, don't you think?

_Greg (a long-time ambivalent Emacs user tired of Emacs Lisp)



I don't think elisp makes much sense out of Emacs. There is nothing 
special about it as a programming language: it's Lisp (and not Scheme) 
and depends on primitives of a text editor frame work from the 80s. 
Porting individual modes or features to Dr Racket (or even Viper/VSI) 
might give better results then reimplementing the intrinsics of the 
overall Emacs package. But that depends on the expectations and 
intentions of the programming users.


--
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] generalised set! in Racket

[Michael Titke]

As the mentioned SRFI states it:
This is a proposal to allow procedure calls that evaluate to the value 
of a location to be used to /set/ the value of the location, when used 
as the first operand of |set!|.


The term location is only used in the introductory part but for those 
who know the way behind the scenes it clearly refers to the concept of 
memory addresses of current register machines. By not introducing the 
domain of memory addresses (where you might as well SETF your graphics 
card ROM, EFI boot loaders and other registered beings in that real 
address space that is then virtualized but still contains your call 
stack) they push you into the world of nameless concepts which would be 
the same as lambda forms without define. Just try this in your favorite 
clean Scheme environment but don't call it algorithmic language then.


With generics it is possible to define the necessary methods for set! - 
one such method exists in GOOPS (sorry!) which is able to set slots of 
objects by accessor. The name or identifier isn't gone yet but its 
sequence of symbols or syntax just looks awful:

(define point (make point #:x 1 #:y 2))
(x point) = 1
(set! (x point) 2)
(x point) = 2

With common sense (and not behind scenes) /x/ denotes both the value as 
well as a method to set it. Other programming systems use the dot syntax 
which works slightly better, e.g. /point.x/./

/
Generics and a generalized /set!/ have been en vogue in the 80s as far 
as I know and have then been substituted by message passing interfaces 
where you usually define your own getters and setters for each and every 
variable which might behind the scenes turn out to be stored on a server 
on the next floor or it might just be your favorite terminal emulation 
dimming some little lights called pixels.


Back to the generalized /set!/: it leaves you in a world of invisible 
pointers or location which might even be called concepts. When one 
starts thinking in abstract concepts and goes from concept to concept 
one might end up where one has to invent new words to grab them 
mentally. This is what Latin is good for. But a generalized set! might 
just do away with that little rest of language that remained in the 
Algorithmic Language Scheme.


I think I'm going to purge some /set!/ methods from VSI/goops.

Regards,
Michael


On 29/06/2015 11:56, Alexey Cherkaev wrote:

Hi all,

Common Lisp has a very useful idiom of SETF that can set values to arbitrary 
places. For example, one can set (1 2)-th item of an array A as:

(SETF (AREF A 1 2) 20.0d0)

Scheme preferred way is to use `*-set!` procedures. However, sometimes it is 
inconvenient. For example, if I want to swap two elements in the array/vector, 
I would like to use `swap`:

(define-syntax swap
   (syntax-rules ()
 ((swap ?place1 ?place2 ?tmp)
  (begin
(set! ?tmp ?place1)
(set! ?place1 ?place2)
(set! ?place2 ?place1)

But it will only work for vectors if `set!` can act as CL's SETF on generalised 
places, such as

(swap (vector-ref v 5) (vector-ref v 3) tmp)

SRFI-17 contains the definition of such a `set!` and I can use it from there 
(AFAIR Racket supports it).

I was wondering if there is more Racket-way of doing this? And is there maybe a 
reason why `set!` wasn't given the same power as SETF?

For example, I was thinking of defining syntax to access my implementation of 
multidimensional arrays
as

(define-syntax aref
   (syntax-rules (set!)
 [(set! (aref ?a ?i ...) ?v) (array-set! ?a ?i ... ?v)]
 [(aref ?a ?i ...) (array-ref ?a ?i ...)]))

but obviously it won't work now as `set!` expects the `id` not an expression 
(`syntax-id-rules` won't work either as `aref` is not an `id`).

Regards, Alexey



--
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] db: nested transactions

[Michael Titke]

On 22/06/2015 11:05, George Neuner wrote:

Hi all,

I have what I hope is a quick question.  WIth appropriate care to pair 
start and commit/rollback, is it safe to use call-with-transaction  
and  start-transaction  together?


e.g.,

  (call-with-transaction dbc
(lambda ()
  :

  (start-transaction dbc #:isolation 'serializable)
 :
  (if (needs-rollback? dbc)
  (rollback-transaction dbc)
  (commit-transaction dbc))

  :
) #:isolation 'read-committed )

or the reverse:

  (start-transaction dbc #:isolation 'repeatable-read)
 :

(call-with-transaction dbc
  (lambda ()
:
  ) #:isolation 'serializable)

 :
  (if (needs-rollback? dbc)
  (rollback-transaction dbc)
  (commit-transaction dbc))



I am adding functionality involving sub-transactions to an existing 
code base that uses call-with-transaction pretty much exclusively and 
I'm hoping not to have to change the existing framework.


Thanks,
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 
mailto:racket-users+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


The documentation says: Calling either commit-transaction or 
rollback-transaction when the open transaction was created by 
call-with-transaction causes an exception to be raised.  But they can 
be nested by further call-with-transaction calls, it says.


Last time I did an O/R mapper (in Java) I decided to put in a safety 
belt and use transaction tokens because non local jumps in GUI code are 
known to occur and involontary nesting may be hard to detect. My O/R 
mapper requested to use a valid transaction token from the GUI code each 
time an object wanted to start a transaction. Different transaction used 
different tokens and unmatched tokens produced an error. I think I saw 
three of these error conditions packed nicely into error messages - all 
in all three of them with testing included. There is the overhead of 
token passing but it's still worth it.


BTW Requesting isolation level support info from MySQL DB made me 
shudder back then: or there was some hidden HyperOracle release beneath 
mysql or that thing just lied about it's capabilities.


--
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] Fast way to map over a list many times, changing ONE element each time?

[Michael Titke]

On 19/06/2015 21:24, Luke Miles wrote:

Say I have a list ls and I want to produce a list of
lists where the i'th list has the i'th element of ls tripled,
but all other elements are the same.

e.g. '(3 5 7) = '((9 5 7) (3 15 7) (3 5 21))

What is a fast way to do this?


I could do a loop with appending.
(define (map-once f ls)
   (let M ([sooner null] [later ls])
 (if (null? later) null
   (cons (append sooner (list (f (car later))) (cdr later))
 (M (append sooner (list (car later))) (cdr later))

- (map-once sqr '(4 5 6))
'((16 5 6) (4 25 6) (4 5 36))

Unfortunately, this is very slow  messy.
I have to do 2 big appends for every element is the return list.


Here is a cleaner-looking, but still slow way:
(define (list-set ls i new-val)
   (let-values ([(sooner later) (split-at ls i)])
 (append sooner (list new-val) (cdr later

(define (map-once f ls)
   (for/list ([i (in-naturals)]
  [elm (in-list ls)])
 (list-set ls i (f elm


I'm thinking a good implementation might use continuations somehow?



I would start out with i lists in a vector of length i and construct 
them according to their index and the index of the current element in 
the source list. The key expressions would be

(make-vector i '())
(when (= vector-idx list-idx) (f ...
(vector-list ...

This way you should be able recurse or iterate with an inner definition. 
Is it better to use single linked lists or double linked lists as the 
internal data graph of the text edit buffer? I think with 64bit 
pointers and up to 90.000 lines as a sane soft maximum single linked 
lists with a register holding the number of the current line on screen 
would perform better and are generally easier to handle. Oops, that was 
not meant to end up here ...


--
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] System Scheme (RnRS): Shared Secret Generator

[Michael Titke]

On 12/06/2015 13:21, Konrad Hinsen wrote:

On 12/06/15 09:15, Michael Titke wrote:


In my understanding the pseudo random number generator is deterministic.
That means for the same input seed /random/ will always return the same
value. This is why one usually has to set a new state for each call of
random.


No, quite on the contrary.

Before going on, please note that I never looked at the specific 
random generator used by Racket. I assume it's one of the popular 
random number generator algorithms. For what follows, it doesn't even 
matter which one.


All pseudorandom generators produce a sequence of numbers. The 
intention is that the sequence should have as little detectable 
correlation as possible. The algorithms differ in how they define this 
goal exactly, and how well they reach it.
Right, it should not be the same number on every call to random but the 
same sequence of numbers for each and every seed. Whenever I use the 
same seed I will get the same sequence of random numbers for the 
sequence of calls to random.





The principle behind all these generators is a chaotic dynamic process 
that transforms the current state of the generator (some finite number 
of bits) into a new state, which is used for the next call. The 
returned value is some function of the state. Setting a new seed 
changes to state to some function of the seed value.


Seeding is provided for two use cases: 1) Reproducibility, mainly for 
software testing. If you set the seed to some constant at the start of 
your program, it will behave exactly the same way whenever it is run. 
2) Real randomization, by setting the seed from some unpredictable 
source, such as the system time. In both cases, the idea is to set the 
seed once at the beginning of a program run.


With your idea in #2 I would reliably produce known sequences depending 
on only 256 original states. Using as much entropy from the pool as my 
current implementation is uncommon but it definitely does not create the 
bias. I abuse the pseudo random number generator only to map these 256 
possibilities onto the list (mathematical vector) of 65 characters. 
Racket's implementation somehow introduces that bias. But IMHO a 
function random (n state/generator) should guarantee a common saturation 
of the destination space.


From the Guile reference:

Note that the initial value of `*random-state*' is the same every
time Guile starts up.  Therefore, if you don't pass a STATE parameter
to the above procedures, and you don't set `*random-state*' to
`(seed-random-state your-seed)', where `your-seed' is something that
_isn't_ the same every time, you'll get the same sequence of random
numbers on every run.

The current system time is highly predictable.




The statistical properties of the pseudo-random sequence hold only for 
an unperturbed sequence, i.e. without changing the seed. If you set 
the seed every time you ask for a random number, your random sequence 
becomes simply some complicated function of your input seed, whose 
statistical properties are hard to predict and most probably not what 
you want.


That does not explain the bias, I guess. I repeat: But IMHO a function 
(random n state/generator) should guarantee a common saturation of the 
destination space when the current state is filled with real randomness. 
Do you really think that seeding with numbers from an entropy pool would 
create such a strong bias. I don't think so. On the contrary it does 
away with the predictable sequences of the 256 original states won by 
using the pure result of reading the randomness device.


If you want to look at the system and do a black box test then the 
result would be:


true randomness / noise - Racket's randomness implementation with a new 
state each time - strongly biased noise


true randomness / noise - Racket's randomness implementation with one 
initial state - one of 256 known sequences


true randomness / noise - GNU-Guile's randomness implementation - noise

BTW the basic formula of cryptography is: Message |+| Randomness - 
Randomness

Now replace Randomness with Racket and try to ...

--
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] System Scheme (RnRS): Shared Secret Generator

[Michael Titke]

I changed from one OS to another and I was missing a simple feature: 
automatic password generation. To fill the gap with a Scheme I 
implemented such a generator as a command line tool respectively /crypto 
sweet/.


After having read /SRFI 27: Sources of Random Bits/ I decided to 
implement my algorithm natively with /Guile 1.8/ and /Racket 6.1/. There 
is some portability of simple RnRS System Scheme programs: right now it 
seems that the heritage of the Scheme Shell (/scsh/) grants 
portability across UNIX/POSIX/SUS systems.


Even when it comes to true randomness as perhaps generated by the noise 
in the low order magnitudes/bits of hardware sensors which is enhanced 
and accessible with the file system device entry /dev/urandom this 
simple System Scheme Script remains portable. Accessing entropy pools on 
other systems should be as easy - perhaps with the foreign function 
interface.


With real entropy pools the need for the interface described by SRFI 27 
vanishes almost completely. It's still a good idea to seed some 
randomizing function with real entropy before using it but randomizing 
functions do IMHO not constitute a domain of their own whereas SRFI 27 
declares them to be.




--
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.
#lang racket

;;
;; mti's Crypto Sweet: Human Typable Shared Secret (System Scheme)
;; (make-passwd.scm)
;;
;; Functional Programming seemed to be orthogonal to system
;; programming where data is passed in /pipelines/ and similar
;; concepts.
;;
;; This software is in the Public Domain as granted by the original
;; author.
;;
;; This implementation creates a human typable shared secret
;; especially for protecting online accounts and it should be in
;; conjunction with keychains or password managers. It is defined to
;; not use certain special characters which are known to be difficult
;; to find if the keyboard layout in software doesn't match the actual
;; inscriptions on the keys. It is designed to be usable with
;; secondary backups. Its shared secrets have the property of being
;; hard (but not impossible) to communicate by oral speech. They are
;; also hard to memorize especially when you can look at them only for
;; a short time. There might be other algorithms based on the
;; knowledge of the syllable structure of common western (and perhaps
;; other) languages that could produce secure /master passwords/ not
;; be held within keychains and password managers.
;;
;; The magnitude of the space of distinct shared secrets is high
;; enough to be considered secure with current authentication routines
;; in use on the Internet. For the original implementation with 65
;; characters and 12 positions it should be: (expt 65 12) which is
;; greater than
;;
;;   (expt 64 12) = (expt (expt 2 6) 12) = (expt 2 72)
;;
;; You can improve it by adding your own preferred special
;; characters. TODO: It should take a command line argument
;; representing the length of the desired shared secret.
;;
;; Please consider changing the shared secrets (Soup of Letters) to
;; your needs: sometimes they force you to use special characters in
;; passwords although real randomness - as employed by this
;; implementation - allows shared secrets without them. Do not change
;; this implementation but add the needed characters to the final
;; shared secret yourself at some random position. A further useful
;; adaption would be insert spaces but beware that they might be
;; difficult to read on secondary backups.
;;

;; No abbreviations here: I want to see the characters.
(define *characters*
  (append (string-list ABCDEFGHIJKLMNOPQRSTUVWXYZ)
  (string-list abcdefghijklmnopqrstuvwxyz)
  (string-list 1234567890)
  (string-list !,.)))
(define *number-of-characters* (length *characters*))
(define *length-of-password* 12)

(display make-passwd: number-of-characters: )
(display *number-of-characters*)
(display ; shared secret size: )
(display *length-of-password*)
(newline)


(define (throw-dices randomness-port)
  (let throw-dices ((n *length-of-password*))
(if (= n 0)
'()
(cons (read-char randomness-port)
  (throw-dices (- n 1))) )))
;(define dices-seed list-string)
;; XXXrnrs-port: racket algorithm/datagraph artifact
(define dices-seed (lambda (dices) (map char-integer dices)))

(display make-passwd: Throwing Dices)
(define randomness-device /dev/urandom) ; should be non-blocking pool access
;; /call-with-input-file/ opens the input device in text mode but see
;; the description of binary mode: no difference on UNIX systems.  If
;; this changes perhaps due to Unicode system libraries we might get a
;; bias into our random data but as we use the dices only as the seed
;; for the randomizer we might get away with 

Re: [racket-users] System Scheme (RnRS): Shared Secret Generator

[Michael Titke]

On 10/06/2015 12:33, Michael Titke wrote:
I changed from one OS to another and I was missing a simple feature: 
automatic password generation. To fill the gap with a Scheme I 
implemented such a generator as a command line tool respectively 
/crypto sweet/.


After having read /SRFI 27: Sources of Random Bits/ I decided to 
implement my algorithm natively with /Guile 1.8/ and /Racket 6.1/. 
There is some portability of simple RnRS System Scheme programs: right 
now it seems that the heritage of the Scheme Shell (/scsh/) grants 
portability across UNIX/POSIX/SUS systems.


Even when it comes to true randomness as perhaps generated by the 
noise in the low order magnitudes/bits of hardware sensors which is 
enhanced and accessible with the file system device entry 
/dev/urandom this simple System Scheme Script remains portable. 
Accessing entropy pools on other systems should be as easy - perhaps 
with the foreign function interface.


With real entropy pools the need for the interface described by SRFI 
27 vanishes almost completely. It's still a good idea to seed some 
randomizing function with real entropy before using it but randomizing 
functions do IMHO not constitute a domain of their own whereas SRFI 27 
declares them to be.




--
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 
mailto:racket-users+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
The expressions used in this text might diverge significantly from usual 
mathematical terminology.

But I didn't study maths at university ...

There seems to be a strong bias in the /Racket/ version (three examples: 
G3GpGGGCuG3u, GGIGYGGGI9GG, mGCnF3G,) with a lot of capital 
letter Gs so please don't use it in production environments.
 This bias is that obvious because there neither is a further 
permutation of the initial character sets nor an obfuscation of the 
result. But this bias might mean that the procedure /random/ is not 
(what I call) /holomorphic/: the procedure /random /does not spread or 
distribute the seed across the destination space (one dimension with a 
magnitude denoted by n). Filling all the 31 bits of the seed might 
produce visually more appealing results but it could as well be as 
strongly biased as the examples given. In my understanding of /random/ 
as an /unstable function/ *the current behavior is **wrong* or I missed 
some point about Racket's randomness. Right now it seems to have the 
opposite effect of an unstable function: it seems to reduce the entropy 
in the given example like a stabilizer where it should act as a 
randomizer ...


The other version does not have such an obvious bias but I have not yet 
analyzed the saturation / distribution and other properties of the 
resulting shared secrets. Right now I do not have the time to check this 
and I don't want to file a bug report as long as I'm not sure about the 
source of the bias.


Regards,
Michael

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