If you only want details about implementation internals you can
always use the source ... Luke!
A wiki on this topic would be very interesting indeed.
Any chance of starting one ?
I'd like to see a book as well of course.
Benedikt
···
On Fri, 21 Jan 2005 02:04:44 +0900, Steven Jenkins wrote:
David G. Andersen wrote:
A book I wish I had the time to write, but I'm swamped:
Using Ruby in Scientific Applications
Maybe we should start a wiki and see where it goes. I'll contribute
something about the data acquisition work I've done with Comedi and Ruby.Steve
(In response to news:41EFE49C.5000107@ieee.org by Steven Jenkins)
Maybe we should start a wiki and see where it goes. I'll contribute
something about the data acquisition work I've done with Comedi and Ruby.
I will contribute with the r4ruby project (R statistical analysis as a Ruby
library), but this has been rescheduled to middle/end of this year.
kaspar
hand manufactured code - www.tua.ch/ruby
Steven Jenkins ha scritto:
David G. Andersen wrote:
A book I wish I had the time to write, but I'm swamped:
Using Ruby in Scientific Applications
- Numerical applications
- Analysis
- Data Acquisition - Control
- Visualization - Data archiving and retrievalMaybe we should start a wiki and see where it goes. I'll contribute something about the data acquisition work I've done with Comedi and Ruby.
maybe start a wikibook on hieraki
Steven Jenkins wrote:
David G. Andersen wrote:
A book I wish I had the time to write, but I'm swamped:
Using Ruby in Scientific Applications
- Numerical applications
- Analysis
- Data Acquisition - Control
- Visualization - Data archiving and retrieval
I thought Ara Howard was working on this book?
···
--
Bil Kleb, Hampton, Virginia
http://fun3d.larc.nasa.gov
Stefan, did you have taken a look at Wee? Or are you using IOWA due to
it's templating engine? Wee is much more like the current Seaside by Avi
Bryant, but not a plain port thereof.
Well, Iowa is production quality, and I needed something right away.
It's quite convenient to work with (after the first date, which would
have turned out quite awkward, had I not found a chapter about it in
a book co-authored by some chap calling himself Stefan Schmiedl).
Together with Kansas, it fits my current needs quite good.
It's still in development,
currently I'm mostly on documenting it:http://www.ntecs.de/viewcvs/viewcvs/*checkout*/Wee/branches/dev/doc/rdoc/index.html?rev=363
Documentation is a Good Thing. I knew about your efforts on Wee (Armin
has mentioned it on our blog somewhere), but I don't have as much
playtime now as I would like to have.
And someone mentioned that he's porting Mewa
(http://www.adrian-lienhard.ch/files/mewa.pdf\) over to Ruby/Wee.I'm currently further on extracting and cleaning up the core of Wee,
which is independent of HTTP and HTML, and includes only the component
logic (the session logic is pretty minimal). Templating is 100%
choosable, but it comes with a programmatical HTML generation API.
Lot's of parts of the source is now very clean, and all together it's
1600 LoC (600 for the core where near to 50% is documention)... And all
memory holes have been fixed.
Looks very promising, Michael. I do hope that business will calm down
a little over the holidays, so that I can catchup on my backlog, after
which I could let it build up again by checking out Wee
s.
···
On Fri, 10 Dec 2004 21:24:41 +0900, Michael Neumann <mneumann@ntecs.de> wrote:
Michael,
"Michael Neumann" <mneumann@ntecs.de> wrote in message
news:41B99583.1040406@ntecs.de...
Stefan, did you have taken a look at Wee? Or are you using IOWA due to
it's templating engine? Wee is much more like the current Seaside by Avi
Bryant, but not a plain port thereof. It's still in development,
currently I'm mostly on documenting it:
Wee is starting to look _really_ attractive. One early suggestion:
Don't bake the "render new
Michael,
"Michael Neumann" <mneumann@ntecs.de> wrote in message
news:41B99583.1040406@ntecs.de...
Stefan, did you have taken a look at Wee? Or are you using IOWA due to
it's templating engine? Wee is much more like the current Seaside by Avi
Bryant, but not a plain port thereof. It's still in development,
currently I'm mostly on documenting it:
Wee is starting to look _really_ attractive. The size is lovely. One early
suggestion:
It may be better to not bake "render new page" into the render phase if that
means a whole new html page. I think something along the lines of partial
page replacement using xmlhttp, and the tiny bit of Javascript magic that
Avi wrote for this, would be a very attractive alternative
(http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&tit
le=Cosying%20up%20to%20the%20client-side&entry=3268075684) It is really a
marvellous facility, and lines up quite well (I think) with Wee::Components.
David G. Andersen wrote:
I just looked at ruby-gsl; hadn't seen it before, but I _like_ it -
thanks, Steven!
Very nice, intuitive, and seems to behave in the way I'd expect
it to for simple things like vector and matrix manipulation.
It has one nice answer to the random number generation point
above, though I suspect there are others.
(Note that FreeBSD's "ruby-gsl" port is actually Ruby/GSL,
not the similarly named "ruby-gsl" project)
Yes, Ruby/GSL is the one I meant. Sorry about the confusion.
Steve
Brian Schröder wrote:
···
On Sun, 12 Dec 2004 15:03:44 +0900 > Joel VanderWerf <vjoel@PATH.Berkeley.EDU> wrote:
David G. Andersen wrote:
A book I wish I had the time to write, but I'm swamped:
Using Ruby in Scientific Applications
- Numerical applications
- Analysis
- Data Acquisition - Control
- Visualization - Data archiving and retrievalI'd be interested in reading that book, and maybe helping out with it. Some more chapters of this hypothetical book that would be nice to have:
- Simulation, modeling, random number generation
- Interfacing with other tools: gnuplot, Matlab, Excel, R, etc.
- Using ruby efficiently: extensions, mmap, narray
- Crafting domain-specific sublanguages for scientific apps
- Ruby and distributed/parallel processing
- Managing legacy C and Fortran code
- Ruby in a real-time environment?Some folks on this list (Ara Howard and Bil Kleb come to mind) are eminently qualified to write on those topics.
+1 From me
+1
Ara?
Regards,
--
Bil Kleb, Hampton, Virginia
That I know well. I wish I could just save some of my time as Ruby is
not the only thing I work on (in fact it's a small slice). Might
better source code documentation help? I don't know which would be
easier as good books are not easy to build overnight. Neither is good
documentation.
Brian M.
···
On Fri, 17 Dec 2004 06:37:12 +0900, Dee.Zsombor@freemail.hu <Dee.Zsombor@freemail.hu> wrote:
If you only want details about implementation internals you can
always use the source ... Luke!
I appreciate the sentiment, but that's like saying that if you want to
understand how a car works you just need to look under the hood.
I've dug through the Ruby source code on more than one occasion to try
to get a handle on some of the trickier aspects of Ruby's
implementation, such as garbage collection or threads. It's easy
enough to see that some isolated function sets some variable to some
value; but without some higher-level explanations of the important
data structures and processes, it's near impossible to understand how
that isolated function fits into the big picture.
And that's why we must all pray that Guy Decoux stays in good health.
···
On Fri, 17 Dec 2004 06:37:12 +0900, Dee.Zsombor@freemail.hu <Dee.Zsombor@freemail.hu> wrote:
If you only want details about implementation internals you can
always use the source ...
Stefan Schmiedl wrote:
Stefan, did you have taken a look at Wee? Or are you using IOWA due to it's templating engine? Wee is much more like the current Seaside by Avi Bryant, but not a plain port thereof.
Well, Iowa is production quality, and I needed something right away.
It's quite convenient to work with (after the first date, which would
have turned out quite awkward, had I not found a chapter about it in
a book co-authored by some chap calling himself Stefan Schmiedl).
Together with Kansas, it fits my current needs quite good.
Sure, Wee is some steps away from production quality, just because important parts have to be reworked (Session, Application classes, which are not in the core ;-)). Nevertheless, those are only a few hundred lines of code...
BTW, would be nice to hear why you did choose IOWA and not Rails. Simply because you did not tried it, or for some other reasons... I'm just curious
It's still in development, currently I'm mostly on documenting it:
http://www.ntecs.de/viewcvs/viewcvs/*checkout*/Wee/branches/dev/doc/rdoc/index.html?rev=363
Documentation is a Good Thing. I knew about your efforts on Wee (Armin
has mentioned it on our blog somewhere), but I don't have as much
playtime now as I would like to have.And someone mentioned that he's porting Mewa (http://www.adrian-lienhard.ch/files/mewa.pdf\) over to Ruby/Wee.
I'm currently further on extracting and cleaning up the core of Wee, which is independent of HTTP and HTML, and includes only the component logic (the session logic is pretty minimal). Templating is 100% choosable, but it comes with a programmatical HTML generation API.
Lot's of parts of the source is now very clean, and all together it's 1600 LoC (600 for the core where near to 50% is documention)... And all memory holes have been fixed.Looks very promising, Michael. I do hope that business will calm down
a little over the holidays, so that I can catchup on my backlog, after
which I could let it build up again by checking out Wee
Hope at that time, Wee is in a much better shape.
Regards,
Michael
···
On Fri, 10 Dec 2004 21:24:41 +0900, > Michael Neumann <mneumann@ntecs.de> wrote:
itsme213 wrote:
Michael,
"Michael Neumann" <mneumann@ntecs.de> wrote in message
news:41B99583.1040406@ntecs.de...Stefan, did you have taken a look at Wee? Or are you using IOWA due to
it's templating engine? Wee is much more like the current Seaside by Avi
Bryant, but not a plain port thereof. It's still in development,
currently I'm mostly on documenting it:Wee is starting to look _really_ attractive. The size is lovely. One early
suggestion:It may be better to not bake "render new page" into the render phase if that
means a whole new html page. I think something along the lines of partial
page replacement using xmlhttp, and the tiny bit of Javascript magic that
Avi wrote for this, would be a very attractive alternative
(http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&tit
le=Cosying%20up%20to%20the%20client-side&entry=3268075684) It is really a
marvellous facility, and lines up quite well (I think) with Wee::Components.
(forwarded to Avi)
I think what you describe is best accomplished with callbacks, that do what the render-phase or action-phase would do. Or maybe with continuations. It's currently not possible to generate a response in the action-phase in Wee. If I change this, and be able to just register an action callback which returns some html, then this should work. Probably, it's only a few lines to change
Not that I would make much use of it, as I think it's only usable in a very few cases, and would probably break portability (JavaScript), but if it results in a simplicification of the current Wee, then I'll implement it.
Regards,
Michael
Sure, Wee is some steps away from production quality, just because
important parts have to be reworked (Session, Application classes, which
are not in the core ;-)). Nevertheless, those are only a few hundred
lines of code...
The fewer, the better!
BTW, would be nice to hear why you did choose IOWA and not Rails. Simply
because you did not tried it, or for some other reasons... I'm just
curious
errm... mainly gut feeling, I guess. There are some default settings
with Rails and its database backend which I don't like. I know that
I can override them, but still ... OTOH, Kansas as Iowa's preferred
backend (I wonder how that sounds to native speaker from Kansas ...)
is both very clever and very small.
I have to admit that I haven't followed the frequent announcement on
Rails improvements thoroughly, but just from the looks, Iowa seemed
easier to setup with it's own Webrick-based HTTP-server and indeed
proved to be absolutely no hassle thanks to the efforts of the rpa
packagers. Moving things between my development machine and the
production server is easy, too, as I just scp a tarball and change
the port webrick listens on.
I'm growing my pages in a single HTML file until they do what they
need. Then I improve code structure until changes in application logic
(mostly) won't influence the HTML part any more. Finally I split the
..iwa part off and refactor the code with the existing base. I will
repeat this until the project is finished.
Back to my gut feeling, which I can now summarize into a single
sentence: I think that Iowa makes things simple, but not too simple.
Hope at that time, Wee is in a much better shape.
Wee will be, even if we will be not
s.
···
On Fri, 10 Dec 2004 22:58:30 +0900, Michael Neumann <mneumann@ntecs.de> wrote:
Michael Neumann ha scritto:
Not that I would make much use of it, as I think it's only usable in a very few cases, and would probably break portability (JavaScript), but if it results in a simplicification of the current Wee, then I'll implement it.
well, if you do some live update stuff with javascript using XmlHTTPRequest you should be fine on mozilla/firefox, IE, safari, recent konqueror and the next opera. It is the stuff used in many widely know things such as flickr.com or gmail, wich have quite a big audience.
(ok, lynx would be out probably
gabriele renzi wrote:
Michael Neumann ha scritto:
Not that I would make much use of it, as I think it's only usable in a very few cases, and would probably break portability (JavaScript), but if it results in a simplicification of the current Wee, then I'll implement it.
well, if you do some live update stuff with javascript using XmlHTTPRequest you should be fine on mozilla/firefox, IE, safari, recent konqueror and the next opera. It is the stuff used in many widely know things such as flickr.com or gmail, wich have quite a big audience.
(ok, lynx would be out probably
okay, I'll implement it
Regards,
Michael
* gabriele renzi <rff_rff@remove-yahoo.it> [1217 12:17]:
Michael Neumann ha scritto:
>Not that I would make much use of it, as I think it's only usable in a
>very few cases, and would probably break portability (JavaScript), but
>if it results in a simplicification of the current Wee, then I'll
>implement it.
>well, if you do some live update stuff with javascript using
XmlHTTPRequest you should be fine on mozilla/firefox, IE, safari, recent
konqueror and the next opera. It is the stuff used in many widely know
things such as flickr.com or gmail, wich have quite a big audience.
(ok, lynx would be out probably
See Google Suggest too:
these guys never cease to boggle my mind when I try to guess how many acres
of computing power they must have to do something like this. I picture scenes
from the Matrix, except with motherboards rather than people in the pods...
···
--
A little rudeness and disrespect can elevate a meaningless interaction
into a battle of wills and add drama to an otherwise dull day. - Calvin discovers Usenet
Rasputin :: Jack of All Trades - Master of Nuns
Michael Neumann ha scritto:
gabriele renzi wrote:
Michael Neumann ha scritto:
Not that I would make much use of it, as I think it's only usable in a very few cases, and would probably break portability (JavaScript), but if it results in a simplicification of the current Wee, then I'll implement it.
well, if you do some live update stuff with javascript using XmlHTTPRequest you should be fine on mozilla/firefox, IE, safari, recent konqueror and the next opera. It is the stuff used in many widely know things such as flickr.com or gmail, wich have quite a big audience.
(ok, lynx would be out probablyokay, I'll implement it
I just noticed that through the blog post referenced from itsme123 you can get here:
http://www.papermountain.org/demos/live/
where the author has a Borges implementation.
I guess you can rip it out, at least the javascript magic
Dick Davies ha scritto:
well, if you do some live update stuff with javascript using XmlHTTPRequest you should be fine on mozilla/firefox, IE, safari, recent konqueror and the next opera. It is the stuff used in many widely know things such as flickr.com or gmail, wich have quite a big audience.
(ok, lynx would be out probablySee Google Suggest too:
even google-groups2 uses a similar interface. And even if nobody "hyped" it, even yahoo mail does
these guys never cease to boggle my mind when I try to guess how many acres
of computing power they must have to do something like this. I picture scenes
from the Matrix, except with motherboards rather than people in the pods...