Re: [dev] Introducing SEE, the Simple Executing Engine
On 24.10.2011 00:10, pancake wrote: Use sloccount. It doesnt matters how do you indent with this tool.. Well, some syntaxes are not handled at all like if().. And if()\n.. But you get proper loccount Thanks for the info. I've used sloccount before but never tried to understand how it computes its results. By the way, if you want want to become rich quickly, use Rails and sloccount: # [code below from the Rails tutorial] rails new blog cd blog rails generate controller home index rails generate scaffold Post name:string title:string content:text sloccount . | grep Cost # $ 5,143
Re: [dev] Introducing SEE, the Simple Executing Engine
Use sloccount. It doesnt matters how do you indent with this tool.. Well, some syntaxes are not handled at all like if().. And if()\n.. But you get proper loccount On 23/10/2011, at 16:01, Pierre Chapuis wrote: > It's a detail, but shouldn't simple_interrupter.c be called > simple_interpreter.c instead? > > Otherwise, I haven't spent so much time looking at it but > the code looks pretty readable. The number of LOCs is > artificially high because of the C coding style, but the > complexity is low. >
Re: [dev] Introducing SEE, the Simple Executing Engine
Install a gcc targetting x86-64 and use -Wall that would be enought. Those bugs are quite obvious If i get some spare time i can look at the code, but actually im kinda out of time for everything :( On 23/10/2011, at 14:55, Xinhao Yuan wrote: > __sa is an old magic to specify the size of gc_header_s, I removed it > in the recent commit. > > For newlisp, I noticed it before. I think one of the difference is > that newlisp is trying to provide a completed I/O routines set, while > SEE is not. SEE may be considered minimalistic :) > > And there is no x86_64 environment for me :(, I may try to create a > x86_64 VM to fix the potential bugs in the code. > > On Sun, Oct 23, 2011 at 7:44 PM, pancake wrote: >> More notes: >> - add a space between -o and the filename when linking. This is also >> breaking the build. >> >> - defining gcheader foo to 24 makes the build happen, but full of >> pointer/int warnings which i imagine this is just wrong pointer arithmetics >> that will result in segfaults. >> >> - im also seeing wrong format strings like using %x instrad of %p .. >> >> - make clean fails >> >> Im not going to execute something that the compilers says its wrong at first >> place. The idea looks cool but needs a big cleanup in order to make it happy >> with pointers and be 64bit friendly. >> >> - i would like it more if the LOCs get under 2kloc :P >> >> On 23/10/2011, at 12:30, Pierre Chapuis wrote: >> >>> On 23.10.2011 12:20, Pierre Chapuis wrote: >>> Precision: breaks *on a 64 bits machine* (gc_header_t is a pointer so gc_header_s is 8 bytes larger than GC_HEADER_SPACE). >>> >>> OK, apparently just setting GC_HEADER_SPACE to 24 makes it build >>> and run simple tests. Sorry for the noise. >>> >> >> >
Re: [dev] Introducing SEE, the Simple Executing Engine
Yeah, my poor English. There are always many stuffs in a language interpreter/compiler. The motivation of the project is to provide a minimal script environment inside other projects. On Sun, Oct 23, 2011 at 10:01 PM, Pierre Chapuis wrote: > It's a detail, but shouldn't simple_interrupter.c be called > simple_interpreter.c instead? > > Otherwise, I haven't spent so much time looking at it but > the code looks pretty readable. The number of LOCs is > artificially high because of the C coding style, but the > complexity is low. > >
Re: [dev] Introducing SEE, the Simple Executing Engine
It's a detail, but shouldn't simple_interrupter.c be called simple_interpreter.c instead? Otherwise, I haven't spent so much time looking at it but the code looks pretty readable. The number of LOCs is artificially high because of the C coding style, but the complexity is low.
Re: [dev] Introducing SEE, the Simple Executing Engine
__sa is an old magic to specify the size of gc_header_s, I removed it in the recent commit. For newlisp, I noticed it before. I think one of the difference is that newlisp is trying to provide a completed I/O routines set, while SEE is not. SEE may be considered minimalistic :) And there is no x86_64 environment for me :(, I may try to create a x86_64 VM to fix the potential bugs in the code. On Sun, Oct 23, 2011 at 7:44 PM, pancake wrote: > More notes: > - add a space between -o and the filename when linking. This is also breaking > the build. > > - defining gcheader foo to 24 makes the build happen, but full of pointer/int > warnings which i imagine this is just wrong pointer arithmetics that will > result in segfaults. > > - im also seeing wrong format strings like using %x instrad of %p .. > > - make clean fails > > Im not going to execute something that the compilers says its wrong at first > place. The idea looks cool but needs a big cleanup in order to make it happy > with pointers and be 64bit friendly. > > - i would like it more if the LOCs get under 2kloc :P > > On 23/10/2011, at 12:30, Pierre Chapuis wrote: > >> On 23.10.2011 12:20, Pierre Chapuis wrote: >> >>> Precision: breaks *on a 64 bits machine* (gc_header_t is a pointer >>> so gc_header_s is 8 bytes larger than GC_HEADER_SPACE). >> >> OK, apparently just setting GC_HEADER_SPACE to 24 makes it build >> and run simple tests. Sorry for the noise. >> > >
Re: [dev] Introducing SEE, the Simple Executing Engine
More notes: - add a space between -o and the filename when linking. This is also breaking the build. - defining gcheader foo to 24 makes the build happen, but full of pointer/int warnings which i imagine this is just wrong pointer arithmetics that will result in segfaults. - im also seeing wrong format strings like using %x instrad of %p .. - make clean fails Im not going to execute something that the compilers says its wrong at first place. The idea looks cool but needs a big cleanup in order to make it happy with pointers and be 64bit friendly. - i would like it more if the LOCs get under 2kloc :P On 23/10/2011, at 12:30, Pierre Chapuis wrote: > On 23.10.2011 12:20, Pierre Chapuis wrote: > >> Precision: breaks *on a 64 bits machine* (gc_header_t is a pointer >> so gc_header_s is 8 bytes larger than GC_HEADER_SPACE). > > OK, apparently just setting GC_HEADER_SPACE to 24 makes it build > and run simple tests. Sorry for the noise. >
Re: [dev] Introducing SEE, the Simple Executing Engine
On Sun, Oct 23, 2011 at 01:37:23PM +0200, pancake wrote: > Notes: > - looks interesting > - mkdir target require to get make working > - does not compile in osx. ( __sa thingy) > - did you tried newlisp? Could be possible to emulate the same functionality of the __sa thingy with the preprocessor?: #if ... # error Something meaningful #endif Regards -- Ricardo (http://r.untroubled.be/)
Re: [dev] Introducing SEE, the Simple Executing Engine
Notes: - looks interesting - mkdir target require to get make working - does not compile in osx. ( __sa thingy) - did you tried newlisp? On 22/10/2011, at 15:47, "Xinhao.Yuan" wrote: > Hello all, I have subscribed this mail list for long time, but it is my first > post here. I would like to introduce SEE, which is a very small script engine > for embedded environment. It has the following advantages: > > > > - Hackable: the code base is small and the API is simple. > > > > - Portable: the dependency is clean (You may even port it to a naked > environment like a OS kernel). the code is full written in C. > > > > - Full functionality: the language model is single-threaded, but concurrency > can be implemented by external calls. And external calls are the only I/Os in > the language (no "standard I/O routines" here). A simple garbage collector is > implemented in SEE. > > > > For myself, I already used SEE in my toy game engine muGE. I hope SEE would > be useful for you guys to enhance the functionality of your softwares. The > copyright of SEE is dedicated to the public domain. > > > > SEE is hosted on github, > > http://github.com/xinhaoyuan/see
Re: [dev] Introducing SEE, the Simple Executing Engine
Oh, this would be a issue on x86_64. I wrote it on my x86 DEBIAN. fixing. On Sun, Oct 23, 2011 at 6:30 PM, Pierre Chapuis wrote: > On 23.10.2011 12:20, Pierre Chapuis wrote: > >> Precision: breaks *on a 64 bits machine* (gc_header_t is a pointer >> so gc_header_s is 8 bytes larger than GC_HEADER_SPACE). > > OK, apparently just setting GC_HEADER_SPACE to 24 makes it build > and run simple tests. Sorry for the noise. > >
Re: [dev] Introducing SEE, the Simple Executing Engine
On 23.10.2011 12:20, Pierre Chapuis wrote: Precision: breaks *on a 64 bits machine* (gc_header_t is a pointer so gc_header_s is 8 bytes larger than GC_HEADER_SPACE). OK, apparently just setting GC_HEADER_SPACE to 24 makes it build and run simple tests. Sorry for the noise.
Re: [dev] Introducing SEE, the Simple Executing Engine
On 23.10.2011 12:08, Pierre Chapuis wrote:
On 22.10.2011 20:54, Rob wrote:
It's a similar compile time check similar to what dwm uses, in this
case, it
checks if gc_header_s is the same size as GC_HEADER_SPACE.
OK, makes sense. But the build breaks because of this, which is
understandable since gc_header_s is defined like this:
struct gc_header_s
{
union
{
struct
{
unsigned char type;
unsigned char mark;
unsigned int prot_level;
gc_header_t next, prev;
};
char __space[GC_HEADER_SPACE];
};
};
Precision: breaks *on a 64 bits machine* (gc_header_t is a pointer
so gc_header_s is 8 bytes larger than GC_HEADER_SPACE).
Re: [dev] Introducing SEE, the Simple Executing Engine
On 22.10.2011 20:54, Rob wrote:
It's a similar compile time check similar to what dwm uses, in this
case, it
checks if gc_header_s is the same size as GC_HEADER_SPACE.
OK, makes sense. But the build breaks because of this, which is
understandable since gc_header_s is defined like this:
struct gc_header_s
{
union
{
struct
{
unsigned char type;
unsigned char mark;
unsigned int prot_level;
gc_header_t next, prev;
};
char __space[GC_HEADER_SPACE];
};
};
Re: [dev] Introducing SEE, the Simple Executing Engine
On 22 October 2011 19:36, Pierre Chapuis wrote: > On 22.10.2011 15:47, Xinhao.Yuan wrote: > >> http://github.com/xinhaoyuan/see > > Looks interesting, but what the hell is that? > > static char __sa[sizeof(gc_header_s) == GC_HEADER_SPACE ? 0 : -1]; It's a similar compile time check similar to what dwm uses, in this case, it checks if gc_header_s is the same size as GC_HEADER_SPACE. Rob
Re: [dev] Introducing SEE, the Simple Executing Engine
On 22.10.2011 15:47, Xinhao.Yuan wrote: http://github.com/xinhaoyuan/see Looks interesting, but what the hell is that? static char __sa[sizeof(gc_header_s) == GC_HEADER_SPACE ? 0 : -1];
[dev] Introducing SEE, the Simple Executing Engine
Hello all, I have subscribed this mail list for long time, but it is my first post here. I would like to introduce SEE, which is a very small script engine for embedded environment. It has the following advantages: - Hackable: the code base is small and the API is simple. - Portable: the dependency is clean (You may even port it to a naked environment like a OS kernel). the code is full written in C. - Full functionality: the language model is single-threaded, but concurrency can be implemented by external calls. And external calls are the only I/Os in the language (no "standard I/O routines" here). A simple garbage collector is implemented in SEE. For myself, I already used SEE in my toy game engine muGE. I hope SEE would be useful for you guys to enhance the functionality of your softwares. The copyright of SEE is dedicated to the public domain. SEE is hosted on github, http://github.com/xinhaoyuan/see
