Re: [Potluck] a lightweight web framework

2013-02-18 Thread Nala Ginrut
Hey guys! Now it's the time to officially release my potluck dish: https://github.com/NalaGinrut/artanis Let me re-introduce it: * just read the README on the link I gave ;-P Happy hacking! Enjoy!

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Daniel Hartwig
On 19 February 2013 00:25, Mike Gran wrote: > From: Noah Lavine >>Hello, >>>On Wed 23 Jan 2013 13:20, Daniel Llorens writes: >>> In [2]: a = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) >>> In [4]: a[1] Out[4]: array([4, 5, 6]) In [5]: a[1, 1] Out[5]: 5 array-re

Re: Precedence for reader extensions

2013-02-18 Thread Mark H Weaver
Hi Mikael, Mikael Djurfeldt writes: > I'm working on an mit-scheme compatibility module (compat mit-scheme) > enabling Guile to read a (so far) subset of mit-scheme code. > > Now I have the problem that mit-scheme has the two constants > #!optional and #!rest (mit-scheme extensions to the scheme

Problems with 'number->string' (was Re: propose deprecation of generalized-vector-*)

2013-02-18 Thread Mark H Weaver
Andy Wingo writes: > On Wed 23 Jan 2013 13:20, Daniel Llorens writes: > >> scheme@(guile-user)> (f64vector-ref #s64(1 2 3) 0) >> $1 = #.# > > Here you are interpreting an int64 as a double, which should work, but > this printed result is really bizarre and looks like a bug in our number > printe

Re: Precedence for reader extensions

2013-02-18 Thread Mikael Djurfeldt
(Sorry for thinking publicly.) The reason why I don't simply use guile-reader but start bugging you about it is that it feels silly that Guile, which was originally supposed to be able to support different languages, can't even support the read syntax of a sibling scheme interpreter. It is somewh

Re: Precedence for reader extensions

2013-02-18 Thread Mikael Djurfeldt
On Mon, Feb 18, 2013 at 10:05 PM, Mikael Djurfeldt wrote: > If anyone is afraid about the effect this would have on reader > performance, it is possible to compile %read-hash-procedures to a > table of flags indicating exceptions. But, given the current interface to reader extensions in the form

Re: Precedence for reader extensions

2013-02-18 Thread Mikael Djurfeldt
On Mon, Feb 18, 2013 at 10:05 PM, Mikael Djurfeldt wrote: > guilehall guildhall (I write too fast)

Precedence for reader extensions

2013-02-18 Thread Mikael Djurfeldt
I'm working on an mit-scheme compatibility module (compat mit-scheme) enabling Guile to read a (so far) subset of mit-scheme code. Now I have the problem that mit-scheme has the two constants #!optional and #!rest (mit-scheme extensions to the scheme standard). I thought that I could support this

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Mike Gran
> From: David Pirotte > do we actually have a matrice calculus [offset based the better] lib or > binding > or > scheme package ? any pointer is welcome There once was a package called guile-num. You can find it here. www.nongnu.org/guile-num But, it would take some work to get it to run aga

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread David Pirotte
Heya, > > One could imagine a Matlab-like syntax where array-ref has to have > > the same number of indices as the underlying array, but, if an > > index were replaced with a symbol, it would return a slice. > > > > if np is [[1, 2, 3], [4, 5, 6], [7, 8, 9]] just in case it would [one day

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Noah Lavine
On Mon, Feb 18, 2013 at 11:25 AM, Mike Gran wrote: > From: Noah Lavine > > I haven't worked with the array functionality, so I might be missing > > something, but I don't see why this is natural for array-ref. > > One could imagine a Matlab-like syntax where array-ref has to have > the same numb

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Mike Gran
From: Noah Lavine >Hello, >>On Wed 23 Jan 2013 13:20, Daniel Llorens writes: >> >>> In [2]: a = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) >> >>> In [4]: a[1] >>> Out[4]: array([4, 5, 6]) >>> In [5]: a[1, 1] >>> Out[5]: 5 >>> >>> array-ref can be extended very simply to do that. It accumulates o

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Noah Lavine
Hello, On Mon, Feb 18, 2013 at 10:55 AM, Andy Wingo wrote: > Hi, > > On Wed 23 Jan 2013 13:20, Daniel Llorens > writes: > > > In [2]: a = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) > > In [4]: a[1] > > Out[4]: array([4, 5, 6]) > > In [5]: a[1, 1] > > Out[5]: 5 > > > > array-ref can be extended

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Andy Wingo
Hi, On Wed 23 Jan 2013 13:20, Daniel Llorens writes: > In [2]: a = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) > In [4]: a[1] > Out[4]: array([4, 5, 6]) > In [5]: a[1, 1] > Out[5]: 5 > > array-ref can be extended very simply to do that. It accumulates on the > position as it is done now, but if

RTL Call Issue

2013-02-18 Thread Noah Lavine
Hello, I've hit an interesting issue in the RTL "call" instruction. I find that I can't execute a call instruction where the return frame starts at the same place that the procedure to call is at - it must start past there. That doesn't match my expected behavior, but I'm not sure if my expectatio

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Andy Wingo
Hi Daniel, On Wed 23 Jan 2013 10:06, Andy Wingo writes: > On Tue 22 Jan 2013 15:31, Daniel Llorens writes: > >> On Jan 21, 2013, at 17:11, Andy Wingo wrote: >> >> The patch attached applies over yours and is to document this function >> and a couple others in the manual. > > Thanks, applied and