Sohail Somani wrote:
> Please port your library to C++.
Sounds like a good exercise for someone who likes C++.
I did a proof of concept once. Anonymous functions are sorely missed,
but at least there is the preprocessor.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
> Sohail Somani wrote:
>> Please port your library to C++.
>
> Sounds like a good exercise for someone who likes C++.
>
> I did a proof of concept once. Anonymous functions are sorely missed,
> but at least there is the preprocessor.
Curious: Have you used other event propagation frameworks? e.g. Qt's
signals/slots?
I've often wondered whether the lack of cell's uptake is because it is
bound too tightly to the CLOS. Cells binds the event source/sink to
CLOS slots. Qt makes you use explicit "signal" and "slot" functions,
but this has the benefit of separating event propagation from the data
structure.
A common use case is one object setting some internal values and then
broadcasting a derived value according to a public API. There is no
place to store this derived value in the signaling class, and the
source and sink sites need not use classes. Sometimes the purpose of
handling signals isn't to change any particular value, but rather
initiate a collection of side effects.
I dunno. Would cells be more successful if it were sold as a few
layered components instead of a single system? e.g. a raw signal/slot
framework, a handful of utilities like synapses and loop detection,
and a CLOS integration built on top?
OOP is sweet, but CL supports a host of other programming models...
Donning my flame-retardant suit,
Daniel
D Herring wrote:
> Ken Tilton wrote:
>
>> Sohail Somani wrote:
>>
>>> Please port your library to C++.
>>
>>
>> Sounds like a good exercise for someone who likes C++.
>>
>> I did a proof of concept once. Anonymous functions are sorely missed,
>> but at least there is the preprocessor.
>
>
> Curious: Have you used other event propagation frameworks?
I think the closest I experienced was some smalltalk pet tricks similar
to what you describe next...
> e.g. Qt's
> signals/slots?
>
> I've often wondered whether the lack of cell's uptake is because it is
> bound too tightly to the CLOS. Cells binds the event source/sink to
> CLOS slots. Qt makes you use explicit "signal" and "slot" functions,
> but this has the benefit of separating event propagation from the data
> structure.
>
> A common use case is one object setting some internal values and then
> broadcasting a derived value according to a public API.
Sounds like the GoF Observer pattern. Yep, I always cite that as prior
art. Too much exposed wiring and work for the developer. I have to say I
am interested in X, with Cells I just use X in the course of normal
coding and away we go.
> There is no
> place to store this derived value in the signaling class, and the source
> and sink sites need not use classes. Sometimes the purpose of handling
> signals isn't to change any particular value, but rather initiate a
> collection of side effects.
>
> I dunno. Would cells be more successful if it were sold as a few
> layered components instead of a single system? e.g. a raw signal/slot
> framework, a handful of utilities like synapses and loop detection, and
> a CLOS integration built on top?
Why not go the other way? To achieve a more painful explicit Observer
pattern requiring me to write all the subscribe/notify code, just create
a couple of classes to play the various roles and then subscribe and
notify explicitly.
>
> OOP is sweet, but CL supports a host of other programming models...
And CLOS is sweet and can be used cleverly to do the Observer pattern. :)
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
>
> Sohail Somani wrote:
>> Please port your library to C++.
>
> Sounds like a good exercise for someone who likes C++.
>
> I did a proof of concept once. Anonymous functions are sorely missed,
> but at least there is the preprocessor.
How did you get through it? It is brutal...
Sohail Somani wrote:
> Ken Tilton wrote:
>
>>
>>
>> Sohail Somani wrote:
>>
>>> Please port your library to C++.
>>
>>
>> Sounds like a good exercise for someone who likes C++.
>>
>> I did a proof of concept once. Anonymous functions are sorely missed,
>> but at least there is the preprocessor.
>
>
> How did you get through it? It is brutal...
Proof of concept is shorthand for "skipped a lot", as in "not getting
through it".
I /did/ experience the phenomenon of "if it compiles it is probably
right". A ton of "debugging" happened as I clawed my way thru to a clean
compile. That was actually cool, but then again I was not exploring, I
was porting.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On May 15, 7:11 am, Ken Tilton <···········@optonline.net> wrote:
> I /did/ experience the phenomenon of "if it compiles it is probably
> right". A ton of "debugging" happened as I clawed my way thru to a clean
> compile. That was actually cool, but then again I was not exploring, I
> was porting.
I experienced the simigliar thing with Haskell, but after paying more
attention to my workflow I found that it's an illusion. The
correctness didn't came from type system, but from revisiting my code
on several passes. Everytime Haskell complained, I revisited my code
and beside fixing some typo I noticed that I'm actually fixing
something else too.
Like:
...
c += v;
int i = double(7);
...
Error:
Can not implicitly convert string to double
...
c += v1;
int = double(7);//??? WTF double it should be triple
...
c += v1;
int = triple(7)
...
Compiles great, everything is correct now .
Ken Tilton wrote:
>
>
> Sohail Somani wrote:
>> Ken Tilton wrote:
>>> I did a proof of concept once. Anonymous functions are sorely missed,
>>> but at least there is the preprocessor.
>>
>>
>> How did you get through it? It is brutal...
>
> Proof of concept is shorthand for "skipped a lot", as in "not getting
> through it".
>
> I /did/ experience the phenomenon of "if it compiles it is probably
> right". A ton of "debugging" happened as I clawed my way thru to a clean
> compile. That was actually cool, but then again I was not exploring, I
> was porting.
Yeah, type correctness == program correctness flames aside, I find that
this is a benefit of C++. I'd still much rather be doing it in CL though.
All the C++ solutions for this problem are so bad it makes me cry.
Sohail Somani wrote:
> Ken Tilton wrote:
>
>>
>>
>> Sohail Somani wrote:
>>
>>> Ken Tilton wrote:
>
>
>>>> I did a proof of concept once. Anonymous functions are sorely
>>>> missed, but at least there is the preprocessor.
>>>
>>>
>>>
>>> How did you get through it? It is brutal...
>>
>>
>> Proof of concept is shorthand for "skipped a lot", as in "not getting
>> through it".
>>
>> I /did/ experience the phenomenon of "if it compiles it is probably
>> right". A ton of "debugging" happened as I clawed my way thru to a
>> clean compile. That was actually cool, but then again I was not
>> exploring, I was porting.
>
>
> Yeah, type correctness == program correctness flames aside, I find that
> this is a benefit of C++. I'd still much rather be doing it in CL though.
>
> All the C++ solutions for this problem are so bad it makes me cry.
Ah, got links? To C++ solutions, I mean.
IIANM, Adobe Adam involved a frickin /preprocessing pass/ before C++
could have at it, taking us back to Blub programmers thinking what they
are doing is normal because, well, it is. I forgot my point.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
> Ah, got links? To C++ solutions, I mean.
Well there is nothing to write home about. There is your typical
observer pattern which is implemented at best with something like boost
signals or Qt's hijacking of an already crazy language. Then at worst
you have all the Java gibberish with lots of objects.
> IIANM, Adobe Adam involved a frickin /preprocessing pass/ before C++
> could have at it, taking us back to Blub programmers thinking what they
> are doing is normal because, well, it is. I forgot my point.
Actually, I thought Adam was the one that held the most promise based on
a presentation I saw. I never checked out the code though. I was under
the impression that it was all done within the confines of the C++ language.
Thanks for reminding me about it, I'll have to take a look.
Sohail
Sohail Somani wrote:
> Ken Tilton wrote:
>> Ah, got links? To C++ solutions, I mean.
>
> Well there is nothing to write home about. There is your typical
> observer pattern which is implemented at best with something like boost
> signals or Qt's hijacking of an already crazy language. Then at worst
> you have all the Java gibberish with lots of objects.
>
>> IIANM, Adobe Adam involved a frickin /preprocessing pass/ before C++
>> could have at it, taking us back to Blub programmers thinking what
>> they are doing is normal because, well, it is. I forgot my point.
>
> Actually, I thought Adam was the one that held the most promise based on
> a presentation I saw. I never checked out the code though. I was under
> the impression that it was all done within the confines of the C++
> language.
>
> Thanks for reminding me about it, I'll have to take a look.
Just took a quick look and boy did I remember wrong. So again, they all
make me cry.
Sohail Somani wrote:
> Sohail Somani wrote:
>
>> Ken Tilton wrote:
>>
>>> Ah, got links? To C++ solutions, I mean.
>>
>>
>> Well there is nothing to write home about. There is your typical
>> observer pattern which is implemented at best with something like
>> boost signals or Qt's hijacking of an already crazy language. Then at
>> worst you have all the Java gibberish with lots of objects.
>>
>>> IIANM, Adobe Adam involved a frickin /preprocessing pass/ before C++
>>> could have at it, taking us back to Blub programmers thinking what
>>> they are doing is normal because, well, it is. I forgot my point.
>>
>>
>> Actually, I thought Adam was the one that held the most promise based
>> on a presentation I saw. I never checked out the code though. I was
>> under the impression that it was all done within the confines of the
>> C++ language.
>>
>> Thanks for reminding me about it, I'll have to take a look.
>
>
> Just took a quick look and boy did I remember wrong. So again, they all
> make me cry.
Pre-processor, eh?
So for what are you waiting? You'll be famous, Adobe will hire you...
don't forget me when you make the red carpet.
It would be so perfect if the C++ community adopted Cells before the
Lisp community. Hmmm, I wonder how Python Trellis is doing...
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On May 16, 6:13 am, Ken Tilton <···········@optonline.net> wrote:
> Sohail Somani wrote:
> > Sohail Somani wrote:
>
> >> Ken Tilton wrote:
>
> >>> Ah, got links? To C++ solutions, I mean.
>
> >> Well there is nothing to write home about. There is your typical
> >> observer pattern which is implemented at best with something like
> >> boost signals or Qt's hijacking of an already crazy language. Then at
> >> worst you have all the Java gibberish with lots of objects.
>
> >>> IIANM, Adobe Adam involved a frickin /preprocessing pass/ before C++
> >>> could have at it, taking us back to Blub programmers thinking what
> >>> they are doing is normal because, well, it is. I forgot my point.
>
> >> Actually, I thought Adam was the one that held the most promise based
> >> on a presentation I saw. I never checked out the code though. I was
> >> under the impression that it was all done within the confines of the
> >> C++ language.
>
> >> Thanks for reminding me about it, I'll have to take a look.
>
> > Just took a quick look and boy did I remember wrong. So again, they all
> > make me cry.
>
> Pre-processor, eh?
>
> So for what are you waiting? You'll be famous, Adobe will hire you...
> don't forget me when you make the red carpet.
>
> It would be so perfect if the C++ community adopted Cells before the
> Lisp community. Hmmm, I wonder how Python Trellis is doing...
>
> kenny
Question How would programming in dataflow lisp look like?
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
> ECLM rant:http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
> ECLM talk:http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en- Hide quoted text -
>
> - Show quoted text -
Slobodan Blazeski wrote:
> On May 16, 6:13 am, Ken Tilton <···········@optonline.net> wrote:
>
>>Sohail Somani wrote:
>>
>>>Sohail Somani wrote:
>>
>>>>Ken Tilton wrote:
>>
>>>>>Ah, got links? To C++ solutions, I mean.
>>
>>>>Well there is nothing to write home about. There is your typical
>>>>observer pattern which is implemented at best with something like
>>>>boost signals or Qt's hijacking of an already crazy language. Then at
>>>>worst you have all the Java gibberish with lots of objects.
>>
>>>>>IIANM, Adobe Adam involved a frickin /preprocessing pass/ before C++
>>>>>could have at it, taking us back to Blub programmers thinking what
>>>>>they are doing is normal because, well, it is. I forgot my point.
>>
>>>>Actually, I thought Adam was the one that held the most promise based
>>>>on a presentation I saw. I never checked out the code though. I was
>>>>under the impression that it was all done within the confines of the
>>>>C++ language.
>>
>>>>Thanks for reminding me about it, I'll have to take a look.
>>
>>>Just took a quick look and boy did I remember wrong. So again, they all
>>>make me cry.
>>
>>Pre-processor, eh?
>>
>>So for what are you waiting? You'll be famous, Adobe will hire you...
>>don't forget me when you make the red carpet.
>>
>>It would be so perfect if the C++ community adopted Cells before the
>>Lisp community. Hmmm, I wonder how Python Trellis is doing...
>>
>>kenny
>
>
> Question How would programming in dataflow lisp look like?
I should post my Fibonacci demo, send the yobbos into another frenzy.
A big gap between Cells and FBP is that Cells do not drag one into a
visual programming environment, nor is the mental model one of linking
circuits. When I author a VisiCalc model, I Just State the Formulas for
each computed cell. If I want to compute off a value not yet in play, I
have to add that spreadsheet cell first. Same with Cells. So the closest
thing in C++ would be -- well, I thought it had it: computed slots? They
look like stateful slots but no value is stored: each time that
"variable" is accessed the function runs.
In Cells, the formulas are an arbitrarily complex form offered as
initforms, default initargs, or as initargs at make-instance time. So a
container that expands to encompass its kids would a local right bound
authored thus:
:lr (c? (+ (outset self) (loop for k in (kids self)
maximizing (pr k))))
pr being the kids right edge in its parents coordinate system, aka
"mine" since I am its parent in the context above. So I am not thinking
about outputs or inputs or wires, I am just writing a block of code
wholly responsible for delivering the slot's value.
There is a /lot/ of code in the Celtk, Cells-Gtk, and even Cello CVS
repositories if you need to see more.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
> :lr (c? (+ (outset self) (loop for k in (kids self)
> maximizing (pr k))))
I'm writing too much code for academic use these days: I can't help it
to suggest
(apply #'max (mapcar #'pr (kids self)))
Which looks as beautiful as inefficient (consing up that mapped list
just to discard it right away again).
Funny thing is that SBCL seems to handle it quite well:
TEST> (defmd obj () pr)
#<STANDARD-CLASS OBJ>
TEST> (defparameter *kids* (loop for x from 0 below 1000 collect
(make-instance 'obj :pr (random 1000))))
*KIDS*
TEST> (time (dotimes (i 1000) (apply #'max (mapcar #'pr *kids*))))
Evaluation took:
0.728 seconds of real time
0.652041 seconds of user run time
0.0 seconds of system run time
[Run times include 0.032 seconds GC run time.]
0 calls to %EVAL
0 page faults and
24,012,560 bytes consed.
NIL
vs.
TEST> (time (dotimes (i 1000) (loop for k in *kids* maximizing (pr k))))
Evaluation took:
0.69 seconds of real time
0.612039 seconds of user run time
0.004 seconds of system run time
[Run times include 0.048 seconds GC run time.]
0 calls to %EVAL
0 page faults and
16,002,944 bytes consed.
NIL
My guess would have been that mapcar should have used a lot more memory
than the looping solution (which in theory does not need to cons at all,
right?)
Interestingly I can't get rid of the consing using dolist either:
TEST> (time (dotimes (i 1000) (let ((max 0)) (dolist (k *kids*) (let
((pr (pr k)))
(if (> pr max) (setf max pr))))
max)))
Evaluation took:
0.667 seconds of real time
0.584037 seconds of user run time
0.004 seconds of system run time
[Run times include 0.016 seconds GC run time.]
0 calls to %EVAL
0 page faults and
15,998,976 bytes consed.
NIL
I'm too lazy to deal with do right now ...
Peter
> pr being the kids right edge in its parents coordinate system, aka
> "mine" since I am its parent in the context above. So I am not thinking
> about outputs or inputs or wires, I am just writing a block of code
> wholly responsible for delivering the slot's value.
>
> There is a /lot/ of code in the Celtk, Cells-Gtk, and even Cello CVS
> repositories if you need to see more.
>
> kt
>
>
On May 16, 1:56 pm, Peter Hildebrandt <·················@gmail.com>
wrote:
> Ken Tilton wrote:
>
> > :lr (c? (+ (outset self) (loop for k in (kids self)
> > maximizing (pr k))))
>
> I'm writing too much code for academic use these days: I can't help it
> to suggest
>
> (apply #'max (mapcar #'pr (kids self)))
>
> Which looks as beautiful as inefficient (consing up that mapped list
> just to discard it right away again).
A tighter functional solution would be
(reduce #'max (kids self) :key #'pr)
and it should (more or less) match loop in memory usage.
Chris Russell wrote:
> A tighter functional solution would be
> (reduce #'max (kids self) :key #'pr)
> and it should (more or less) match loop in memory usage.
Funny thing is, I thought of reduce, too, and tried it out. It looks
elegant, after all.
Interestingly reduce is slower than apply in this case. Loop remains
the clear winner with the fastest runtime and without consing.
apply/mapcar conses, but is still faster than reduce.
NET-ED> (defclass obj () ((pr :accessor pr :initarg :pr)))
NET-ED> (defparameter *kids* (loop for i from 0 below 1000 collect
(make-instance 'obj :pr (random 1000))))
NET-ED> (time (dotimes (i 1000) (reduce #'max *kids* :key #'pr)))
Evaluation took:
0.315 seconds of real time
0 bytes consed.
NET-ED> (time (dotimes (i 1000) (loop for x in *kids* maximize (pr x))))
Evaluation took:
0.175 seconds of real time
0 bytes consed.
NET-ED> (time (dotimes (i 1000) (apply #'max (mapcar #'pr *kids*))))
Evaluation took:
0.254 seconds of real time
8,007,680 bytes consed.
My guess is that reduce's strategy of calling max on pairs leads to a
lot more overhead than apply's calling max on the whole list.
(let ((count 0)) (dotimes (i 1000) (reduce #'(lambda (x y) (incf count)
(max x y)) *kids* :key #'pr)) count)
999000
i.e. max gets called nearly a million times.
Peter Hildebrandt <·················@gmail.com> writes:
> Ken Tilton wrote:
>> :lr (c? (+ (outset self) (loop for k in (kids self)
>> maximizing (pr k))))
>
> I'm writing too much code for academic use these days: I can't help
> it to suggest
>
> (apply #'max (mapcar #'pr (kids self)))
>
> Which looks as beautiful as inefficient (consing up that mapped list
> just to discard it right away again).
>
> Funny thing is that SBCL seems to handle it quite well:
> [...]
> My guess would have been that mapcar should have used a lot more
> memory than the looping solution (which in theory does not need to
> cons at all, right?)
Yes, but section 11.1.2.1.2 is here to allow implementations to
open code and heavily optimize any CL operator.
http://www.lisp.org/HyperSpec/Body/sec_11-1-2-1-2.html
--
__Pascal Bourguignon__
Peter Hildebrandt <·················@gmail.com> writes:
> TEST> (defmd obj () pr)
> #<STANDARD-CLASS OBJ>
> TEST> (defparameter *kids* (loop for x from 0 below 1000 collect
> (make-instance 'obj :pr (random 1000))))
> *KIDS*
[...]
> TEST> (time (dotimes (i 1000) (loop for k in *kids* maximizing (pr k))))
> Evaluation took:
> 0.69 seconds of real time
> 0.612039 seconds of user run time
> 0.004 seconds of system run time
> [Run times include 0.048 seconds GC run time.]
> 0 calls to %EVAL
> 0 page faults and
> 16,002,944 bytes consed.
> NIL
>
> My guess would have been that mapcar should have used a lot more
> memory than the looping solution (which in theory does not need to
> cons at all, right?)
That doesn't look like something that should cons in practice either,
unless there's something strange going on in that DEFMD macro, which
makes calling PR cons. And the times you're reporting are really
outrageously slow for what is essentially just 1 million method
calls. Here's what I get:
(defclass obj () ((pr :accessor pr :initarg :pr)))
(defparameter *kids* (loop for x from 0 below 1000 collect
(make-instance 'obj :pr (random 1000))))
(time (dotimes (i 1000) (loop for k in *kids* maximizing (pr k))))
Evaluation took:
0.02 seconds of real time
0.018997 seconds of user run time
0.0 seconds of system run time
0 calls to %EVAL
0 page faults and
0 bytes consed.
--
Juho Snellman
Juho Snellman wrote:
> Peter Hildebrandt <·················@gmail.com> writes:
>> My guess would have been that mapcar should have used a lot more
>> memory than the looping solution (which in theory does not need to
>> cons at all, right?)
>
> That doesn't look like something that should cons in practice either,
> unless there's something strange going on in that DEFMD macro, which
> makes calling PR cons. And the times you're reporting are really
> outrageously slow for what is essentially just 1 million method
> calls. Here's what I get:
Thanks Juho. Indeed I was meassuring the overhead of the cells
machinery here. I guess it was the fact that Ken's example was about
cells/kids that primed me to use defmd.
With defclass I get
Evaluation took:
0.189 seconds of real time
0.104007 seconds of user run time
0.0 seconds of system run time
0 calls to %EVAL
0 page faults and
0 bytes consed.
As side effect we learned that cells conses some 16 bytes for every call
to a slot accessor.
The difference to mapcar becomes apparent in this constellation (as
expected):
TEST2> (time (dotimes (i 1000) (apply #'max (mapcar #'pr *kids*))))
Evaluation took:
0.26 seconds of real time
0.184011 seconds of user run time
0.004001 seconds of system run time
[Run times include 0.04 seconds GC run time.]
0 calls to %EVAL
0 page faults and
8,007,680 bytes consed.
Thanks for clearing this up!
However, this does not explain why my machine is 10 times slower than
yours. Let's see: I have a 1.4Ghz Pentium M, usually speed stepping at
around 600Mhz. A current cpu operates at roughly 5 times the clockspeed
(which should scale roughly linearly for this problem), and four years
of processor design could explain a 100% speedup in the FPU.
Additionally, I use a precompiled binary of SBCL (1.0.11.debian), so I
miss out on architecture specific optimizations.
So after all, theory and practive line up nicely.
Thanks again,
Peter
> (defclass obj () ((pr :accessor pr :initarg :pr)))
> (defparameter *kids* (loop for x from 0 below 1000 collect
> (make-instance 'obj :pr (random 1000))))
> (time (dotimes (i 1000) (loop for k in *kids* maximizing (pr k))))
>
> Evaluation took:
> 0.02 seconds of real time
> 0.018997 seconds of user run time
> 0.0 seconds of system run time
> 0 calls to %EVAL
> 0 page faults and
> 0 bytes consed.
>
On May 16, 11:49 am, Ken Tilton <···········@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > On May 16, 6:13 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>Sohail Somani wrote:
>
> >>>Sohail Somani wrote:
>
> >>>>Ken Tilton wrote:
>
> >>>>>Ah, got links? To C++ solutions, I mean.
>
> >>>>Well there is nothing to write home about. There is your typical
> >>>>observer pattern which is implemented at best with something like
> >>>>boost signals or Qt's hijacking of an already crazy language. Then at
> >>>>worst you have all the Java gibberish with lots of objects.
>
> >>>>>IIANM, Adobe Adam involved a frickin /preprocessing pass/ before C++
> >>>>>could have at it, taking us back to Blub programmers thinking what
> >>>>>they are doing is normal because, well, it is. I forgot my point.
>
> >>>>Actually, I thought Adam was the one that held the most promise based
> >>>>on a presentation I saw. I never checked out the code though. I was
> >>>>under the impression that it was all done within the confines of the
> >>>>C++ language.
>
> >>>>Thanks for reminding me about it, I'll have to take a look.
>
> >>>Just took a quick look and boy did I remember wrong. So again, they all
> >>>make me cry.
>
> >>Pre-processor, eh?
>
> >>So for what are you waiting? You'll be famous, Adobe will hire you...
> >>don't forget me when you make the red carpet.
>
> >>It would be so perfect if the C++ community adopted Cells before the
> >>Lisp community. Hmmm, I wonder how Python Trellis is doing...
>
> >>kenny
>
> > Question How would programming in dataflow lisp look like?
>
> I should post my Fibonacci demo, send the yobbos into another frenzy.
>
> A big gap between Cells and FBP is that Cells do not drag one into a
> visual programming environment, nor is the mental model one of linking
> circuits. When I author a VisiCalc model, I Just State the Formulas for
> each computed cell. If I want to compute off a value not yet in play, I
> have to add that spreadsheet cell first. Same with Cells. So the closest
> thing in C++ would be -- well, I thought it had it: computed slots? They
> look like stateful slots but no value is stored: each time that
> "variable" is accessed the function runs.
>
> In Cells, the formulas are an arbitrarily complex form offered as
> initforms, default initargs, or as initargs at make-instance time. So a
> container that expands to encompass its kids would a local right bound
> authored thus:
>
> :lr (c? (+ (outset self) (loop for k in (kids self)
> maximizing (pr k))))
>
> pr being the kids right edge in its parents coordinate system, aka
> "mine" since I am its parent in the context above. So I am not thinking
> about outputs or inputs or wires, I am just writing a block of code
> wholly responsible for delivering the slot's value.
>
> There is a /lot/ of code in the Celtk, Cells-Gtk, and even Cello CVS
> repositories if you need to see more.
>
> kt
Thanks for the explanation. I toyed with cells a little but problem is
that OO is usually not my style, I don't see the world as objects
( probably symptoms of grahamitis). Anyway you got me curious for
dataflow. I read http://www.jpaulmorrison.com/fbp/book.pdf and got
some interesthing ideas. Too bad I couldn't found an implementation to
try it, everything was unworkable. So I dowloaded LabView and the
concept is becoming more and more interesthing.
I think dataflow has a shot at solving implicit paralelism.
Did you ever worked with Linda?
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
> ECLM rant:http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
> ECLM talk:http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en- Hide quoted text -
BTW cool videos but keep the ocean noise down
>
> - Show quoted text -
Slobodan Blazeski wrote:
> On May 16, 11:49 am, Ken Tilton <···········@optonline.net> wrote:
>
>>Slobodan Blazeski wrote:
>>
>>>On May 16, 6:13 am, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>Sohail Somani wrote:
>>
>>>>>Sohail Somani wrote:
>>
>>>>>>Ken Tilton wrote:
>>
>>>>>>>Ah, got links? To C++ solutions, I mean.
>>
>>>>>>Well there is nothing to write home about. There is your typical
>>>>>>observer pattern which is implemented at best with something like
>>>>>>boost signals or Qt's hijacking of an already crazy language. Then at
>>>>>>worst you have all the Java gibberish with lots of objects.
>>
>>>>>>>IIANM, Adobe Adam involved a frickin /preprocessing pass/ before C++
>>>>>>>could have at it, taking us back to Blub programmers thinking what
>>>>>>>they are doing is normal because, well, it is. I forgot my point.
>>
>>>>>>Actually, I thought Adam was the one that held the most promise based
>>>>>>on a presentation I saw. I never checked out the code though. I was
>>>>>>under the impression that it was all done within the confines of the
>>>>>>C++ language.
>>
>>>>>>Thanks for reminding me about it, I'll have to take a look.
>>
>>>>>Just took a quick look and boy did I remember wrong. So again, they all
>>>>>make me cry.
>>
>>>>Pre-processor, eh?
>>
>>>>So for what are you waiting? You'll be famous, Adobe will hire you...
>>>>don't forget me when you make the red carpet.
>>
>>>>It would be so perfect if the C++ community adopted Cells before the
>>>>Lisp community. Hmmm, I wonder how Python Trellis is doing...
>>
>>>>kenny
>>
>>>Question How would programming in dataflow lisp look like?
>>
>>I should post my Fibonacci demo, send the yobbos into another frenzy.
>>
>>A big gap between Cells and FBP is that Cells do not drag one into a
>>visual programming environment, nor is the mental model one of linking
>>circuits. When I author a VisiCalc model, I Just State the Formulas for
>>each computed cell. If I want to compute off a value not yet in play, I
>>have to add that spreadsheet cell first. Same with Cells. So the closest
>>thing in C++ would be -- well, I thought it had it: computed slots? They
>>look like stateful slots but no value is stored: each time that
>>"variable" is accessed the function runs.
>>
>>In Cells, the formulas are an arbitrarily complex form offered as
>>initforms, default initargs, or as initargs at make-instance time. So a
>>container that expands to encompass its kids would a local right bound
>>authored thus:
>>
>> :lr (c? (+ (outset self) (loop for k in (kids self)
>> maximizing (pr k))))
>>
>>pr being the kids right edge in its parents coordinate system, aka
>>"mine" since I am its parent in the context above. So I am not thinking
>>about outputs or inputs or wires, I am just writing a block of code
>>wholly responsible for delivering the slot's value.
>>
>>There is a /lot/ of code in the Celtk, Cells-Gtk, and even Cello CVS
>>repositories if you need to see more.
>>
>>kt
>
>
> Thanks for the explanation. I toyed with cells a little but problem is
> that OO is usually not my style, I don't see the world as objects
> ( probably symptoms of grahamitis).
Then don't look at Cells as OO, look past the implementation to the
ideas. Is RDF OO? No. Is there a TripleCells? Turn down the ocean.
kt
On May 20, 11:31 am, Ken Tilton <···········@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > On May 16, 11:49 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>Slobodan Blazeski wrote:
>
> >>>On May 16, 6:13 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>Sohail Somani wrote:
>
> >>>>>Sohail Somani wrote:
>
> >>>>>>Ken Tilton wrote:
>
> >>>>>>>Ah, got links? To C++ solutions, I mean.
>
> >>>>>>Well there is nothing to write home about. There is your typical
> >>>>>>observer pattern which is implemented at best with something like
> >>>>>>boost signals or Qt's hijacking of an already crazy language. Then at
> >>>>>>worst you have all the Java gibberish with lots of objects.
>
> >>>>>>>IIANM, Adobe Adam involved a frickin /preprocessing pass/ before C++
> >>>>>>>could have at it, taking us back to Blub programmers thinking what
> >>>>>>>they are doing is normal because, well, it is. I forgot my point.
>
> >>>>>>Actually, I thought Adam was the one that held the most promise based
> >>>>>>on a presentation I saw. I never checked out the code though. I was
> >>>>>>under the impression that it was all done within the confines of the
> >>>>>>C++ language.
>
> >>>>>>Thanks for reminding me about it, I'll have to take a look.
>
> >>>>>Just took a quick look and boy did I remember wrong. So again, they all
> >>>>>make me cry.
>
> >>>>Pre-processor, eh?
>
> >>>>So for what are you waiting? You'll be famous, Adobe will hire you...
> >>>>don't forget me when you make the red carpet.
>
> >>>>It would be so perfect if the C++ community adopted Cells before the
> >>>>Lisp community. Hmmm, I wonder how Python Trellis is doing...
>
> >>>>kenny
>
> >>>Question How would programming in dataflow lisp look like?
>
> >>I should post my Fibonacci demo, send the yobbos into another frenzy.
>
> >>A big gap between Cells and FBP is that Cells do not drag one into a
> >>visual programming environment, nor is the mental model one of linking
> >>circuits. When I author a VisiCalc model, I Just State the Formulas for
> >>each computed cell. If I want to compute off a value not yet in play, I
> >>have to add that spreadsheet cell first. Same with Cells. So the closest
> >>thing in C++ would be -- well, I thought it had it: computed slots? They
> >>look like stateful slots but no value is stored: each time that
> >>"variable" is accessed the function runs.
>
> >>In Cells, the formulas are an arbitrarily complex form offered as
> >>initforms, default initargs, or as initargs at make-instance time. So a
> >>container that expands to encompass its kids would a local right bound
> >>authored thus:
>
> >> :lr (c? (+ (outset self) (loop for k in (kids self)
> >> maximizing (pr k))))
>
> >>pr being the kids right edge in its parents coordinate system, aka
> >>"mine" since I am its parent in the context above. So I am not thinking
> >>about outputs or inputs or wires, I am just writing a block of code
> >>wholly responsible for delivering the slot's value.
>
> >>There is a /lot/ of code in the Celtk, Cells-Gtk, and even Cello CVS
> >>repositories if you need to see more.
>
> >>kt
>
> > Thanks for the explanation. I toyed with cells a little but problem is
> > that OO is usually not my style, I don't see the world as objects
> > ( probably symptoms of grahamitis).
>
> Then don't look at Cells as OO, look past the implementation to the
> ideas.
Ideas are great.
>Turn down the ocean.
ROFL
cheers
Bobi
>
> kt- Hide quoted text -
>
> - Show quoted text -
From: Paul Tarvydas
Subject: Re: Cells: Request for Kenny Tilton
Date:
Message-ID: <g11sfq$k4v$1@aioe.org>
Slobodan Blazeski wrote:
> I think dataflow has a shot at solving implicit paralelism.
Reactive programming has the shot. Dataflow is just an overly-complicated,
restricted subset of reactive programming.
Parallelism will be solved using explicit parallelism, not implicit
parallelism.
pt
Paul Tarvydas wrote:
> Slobodan Blazeski wrote:
>
>> I think dataflow has a shot at solving implicit paralelism.
>
> Reactive programming has the shot. Dataflow is just an overly-complicated,
> restricted subset of reactive programming.
>
> Parallelism will be solved using explicit parallelism, not implicit
> parallelism.
I'm not quite sure what you mean by reactive programming but I've quite
comfortably parallelized a data flow graph.
Sohail
From: Paul Tarvydas
Subject: Re: Cells: Request for Kenny Tilton
Date:
Message-ID: <g1ejsj$8te$1@aioe.org>
Sohail Somani wrote:
> I'm not quite sure what you mean by reactive programming but I've quite
> comfortably parallelized a data flow graph.
I consider reactive programming to be that in which software sits idle until
an input arrives. The input causes some action (or chain of actions) to
occur, then the software returns to the idle state.
Number-crunching algorithms are not reactive by this definition.
GUI's, embedded systems, network protocols and a surprising number of many
other common software problems are reactive.
Many of these problems have traditionally been solved using non-reactive
languages, hence, the solutions turn out to be harder than necessary
(e.g. "protocols" are presumed to be "hard"). Non-reactive languages (C,
et al), have the common characteristic that they impose a call-return
protocol at very low levels. Call-return imposes unnecessary
synchronization and hinders parallelization.
The dataflow paradigm is reactive, but constrained. As I understand it, in
dataflow, one designs reactive units that fire only when all inputs have
arrived. For example, a "c = a + b" component computes 'c' only when
both, 'a' and 'b' inputs, have arrived. It is illegal to have two 'a'
inputs arrive before any 'b' inputs arrive.
As I understand it, Cells is reactive. That's probably why it is easy and
fun to build GUI's in Cells.
True parallelism can only be achieved if every "thread" runs as far as it
can, as fast as it can, up to the next point of synchronization.
As I see it, you can only achieve true parallelism by building software
using asynchronous reactive units that fire "events" at each other - and
don't wait for responses (i.e. no implicit call-return). Synchronization,
when called for by the design, must be programmed explicitly.
I've been working, on and off, with a reactive language for almost two
decades. One of the side benefits of the event-based/reactive paradigm is
that it allows one to draw semantically complete diagrams of software (i.e.
the diagrams can be parsed and compiled by a compiler).
pt
On Mon, 26 May 2008 11:15:25 -0400, Paul Tarvydas
<········@visualframeworksinc.com> wrote:
>The dataflow paradigm is reactive, but constrained. As I understand it, in
>dataflow, one designs reactive units that fire only when all inputs have
>arrived. For example, a "c = a + b" component computes 'c' only when
>both, 'a' and 'b' inputs, have arrived.
Yes.
>It is illegal to have two 'a' inputs arrive before any 'b' inputs arrive.
That would be a systolic system. Dataflow architectures frequently
used queues or associative memory to buffer unmatched inputs until
needed.
>As I understand it, Cells is reactive. That's probably why it is easy and
>fun to build GUI's in Cells.
I haven't used or looked closely at Cells, so I'm not sure whether
Cells internally is really reactive or is just some kind of
feed-forward chaining mechanism. But from the descriptions I've read
here the net effect appears to be dataflow.
>As I see it, you can only achieve true parallelism by building software
>using asynchronous reactive units that fire "events" at each other - and
>don't wait for responses (i.e. no implicit call-return). Synchronization,
>when called for by the design, must be programmed explicitly.
Not the only way, but I think it's a damn good one.
George
--
for email reply remove "/" from address
George Neuner wrote:
> On Mon, 26 May 2008 11:15:25 -0400, Paul Tarvydas
> <········@visualframeworksinc.com> wrote:
>
>
>
>>The dataflow paradigm is reactive, but constrained. As I understand it, in
>>dataflow, one designs reactive units that fire only when all inputs have
>>arrived. For example, a "c = a + b" component computes 'c' only when
>>both, 'a' and 'b' inputs, have arrived.
>
>
> Yes.
>
>
>>It is illegal to have two 'a' inputs arrive before any 'b' inputs arrive.
>
>
> That would be a systolic system. Dataflow architectures frequently
> used queues or associative memory to buffer unmatched inputs until
> needed.
Wow, that sounds like all-events-all-the-time. Cells represents the odd
event-ish slot (good for absorbing OS events) by mediating it with what
are known as ephemeral Cells, meaning unlike most Cells they lose their
value as soon as they have propagated it to other cells. But anyone
reading that slots sees NIL, not "un-arrived", and is free to recompute
if some other dependency trigegrs them.
Other cells are what I call steady-state: they take on a value and keep
it until some input changes kicks them off to recalculate.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
> I did a proof of concept once. Anonymous functions are sorely missed,
> but at least there is the preprocessor.
The C++ Boost Frameworks has a Lambda implementation. I don't know how they
did it, it is a lot of template magic and the syntax doesn't looks nice,
but it works:
http://www.boost.org/doc/libs/1_35_0/doc/html/lambda.html
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On May 15, 8:16 am, Frank Buss <····@frank-buss.de> wrote:
> Ken Tilton wrote:
> > I did a proof of concept once. Anonymous functions are sorely missed,
> > but at least there is the preprocessor.
>
> The C++ Boost Frameworks has a Lambda implementation. I don't know how they
> did it, it is a lot of template magic and the syntax doesn't looks nice,
> but it works:
>
> http://www.boost.org/doc/libs/1_35_0/doc/html/lambda.html
>
> --
> Frank Buss, ····@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de
Almost every language is turing complete so it is possible bus as
Steve Yegge says:
"but it's a LOT of work, like pushing a dead horse down the street.
It's about that pleasant, too."
http://steve.yegge.googlepages.com/lisp-wins
So wherever somebody says that something is possible in some language
it reminds me of McCarthy question :
"Could Python could GRACEFULLY manipulate Python code as data?"
The secret is in gracefully. If a tool is hard and inconvenient to use
people will avoid it.
Frank Buss <··@frank-buss.de> writes:
> The C++ Boost Frameworks has a Lambda implementation. I don't know how they
> did it, it is a lot of template magic and the syntax doesn't looks nice,
> but it works
if you squint the right way, then it can be said to provide
dynamic-extent closures.
but not real closures.
cheers,
--m
Michael Livshin wrote:
> Frank Buss <··@frank-buss.de> writes:
>
>
>>The C++ Boost Frameworks has a Lambda implementation. I don't know how they
>>did it, it is a lot of template magic and the syntax doesn't looks nice,
>>but it works
Cool. Yes, the syntax is scary. All the C++ syntax is scary. Can you
believe people say Lisp's problem is the syntax? :)
>
>
> if you squint the right way, then it can be said to provide
> dynamic-extent closures.
>
> but not real closures.
That would be OK, tho obviously a step down. I always remind myself at
times like this that Blub users won't miss feature X in Cells never
having had feature X anywhere else. Like Java. Cells in Java looked
horrendous to me without macros to hide the boilerplate and using
anonymous classes just to get lambda, but... reminds me of a great New
Yorker cartoon, two female hippotamuses on the shore watching it seems a
male swimming by. One says to the other, "He is almost too handsome."
Something like that.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
> Cool. Yes, the syntax is scary. All the C++ syntax is scary. Can you
> believe people say Lisp's problem is the syntax? :)
Well said!
Ken Tilton <···········@optonline.net> writes:
> Sohail Somani wrote:
>> Please port your library to C++.
>
> Sounds like a good exercise for someone who likes C++.
>
> I did a proof of concept once. Anonymous functions are sorely missed,
> but at least there is the preprocessor.
Use boost::bind and boost::lambda:
transform(v.begin(),v.end(),u.begin(),
boost::bind(std::plus<float>(),boost::bind(::sin,_1),boost::bind(::cos,_1)));
is the C++ for:
(map-into u (lambda (x) (+ (sin x) (cos x))) v)
--
__Pascal Bourguignon__