Thanks Pancake. Agree, I'll drop the [ ] to use ( )
I have not announced it yet because I still have problems returning lambdas, and also because I do not have introspection yet (just a snippet to play around) (And also because my wife is back from vacation, which means I have less spare time. He he!!) Ahh....I forgot to mention that it provides a .vapi, and an example in Vala. Actually, I tried to write it in Vala, but C was more convenient because it allows more control. On Wed, Jan 19, 2011 at 5:46 AM, pancake <[email protected]> wrote: > Hi again, > > I've been reading a bit more of gel. I thought it was generating C code, but > it is interpreted, > so it takes no sense to merge it in Vala. But I still think that having a > lispy syntax for > Vala would be great. > > About brackets vs parenthesis. You say in README that you choose [] because > they are > easier to type. Thats not true at all, it depends on the keyboard and the > layout. it's ok > for a PC keyboard with english layout, but not for spanish for example, and > on smartphone > keyboards () are more accessible than []. > > And for readability I think that () looks better than []. > > I would love to see a REPL interface in Gel. > > Nice work :D the idea of being able to access any objects from a running > application using > a GObject-based lisp-like language sounds great. > > --pancake > > On 01/18/11 21:26, Sandino Flores Moreno wrote: >> >> My grain of salt. >> >> I started, just for fun, a programming language for glib named gel: >> https://github.com/tigrux/gel >> >> And the benchmark I made, calculates all the primes between 2 and 50k. >> https://github.com/tigrux/gel/blob/master/comparison/primes.gel >> >> >> [var sieve [array]] >> >> [for n [range 2 50000] >> [if [all [lambda [i] [% n i]] sieve] >> [append sieve n] >> ] >> ] >> >> [print "Calculated " [len sieve] " primes"] >> >> [quit] >> >> > > >> 1) In the first stages, it used gobjects, it was taking around 2 minutes. >> >> 2) Then, I moved to use only compact classes, the time decreased to 40 >> seconds. >> >> 3) After that, I implemented a mechanism to reuse objects, based on a >> pool, >> to avoid calls to g_new, g_free and g_hash_table_new. It then >> decreased to 30 seconds. >> (that mechanism is currently out of git, because conflicted other >> experiments) >> >> 4) Finally, instead of using g_value_get_int, g_value_set_double, etc >> I used macros >> to directly get the fields from the GValue structure. The time >> decreased from 30 to 20 seconds. >> >> The same code, in python, takes only 2 seconds. >> >> So, no matter if your code is in C or not, there is always lot of room >> for improvements, >> specially because GLib/GObject tends to have much code to validate and be >> safe, >> that make it slow but trustful. >> >> >> >> >> 2011/1/18 Jan Hudec<[email protected]>: >>> >>> On Tue, Jan 18, 2011 at 09:18:06 -0300, Erick Pérez Castellanos wrote: >>>> >>>> I haven't prove it but theoretically can't be slower since Mono >>>> applications are running on the top of a virtual machine and Vala >>>> applications are native code executed, so kinda hard to think that >>>> Mono is faster than Vala, eh !!! >>> >>> Theoretically, that's not true. >>> >>> Good just-in-timing run core can run virtual machine code at almost the >>> same >>> speed as native code. And a good garbage-collector is faster than >>> malloc/free >>> (it pays some cost for surviving object, but for many short-lived >>> objects, it >>> is a lot faster) and compacts the working set, which improves cache >>> performance. And these days, memory access cost as much as tens of >>> instructions, so cache performance can make huge difference. >>> >>> Of course the cost of using garbage collector is bigger memory >>> consumption, >>> because the objects are not recycled immediately. >>> >>> -- >>> Jan 'Bulb' >>> Hudec<[email protected]> >>> _______________________________________________ >>> vala-list mailing list >>> [email protected] >>> http://mail.gnome.org/mailman/listinfo/vala-list >>> >> _______________________________________________ >> vala-list mailing list >> [email protected] >> http://mail.gnome.org/mailman/listinfo/vala-list >> > > _______________________________________________ vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
