ficl-developers Mailing List for Ficl - small systems scripting with OO (Page 2)
Brought to you by:
jsadler
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(25) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(13) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Chris D. <chr...@do...> - 2002-03-22 01:11:50
|
Is there any chance of seeing COMPILE, [COMPILE] and/or CODE in the near future of ficl? A bit of forth code I've been working with uses these a fair bit. Is there a way of working around the absence of these words? Or are they there and I'm missing them? Chris. -- Chris Double chr...@do... |
From: David M. <da...@re...> - 2001-12-16 06:10:37
|
Hi all, I'm in need of some FICL classes for implementing data tables, as building blocks for database capability. The idea I have in mind is a generic 'data table' class, we could call 'c-table'. Instances of 'c-table' would be bound to another specific class, and would simply hold an array of n instances of that class. c-table would have methods for: * loading the entire table from a data file * saving the entire table to a data file * appending a new instance of the bound class * deleting an instance of the bound class * actual instance chosen could be selected by an array index, or a hash string field. * searching for an instance of the class matching a key field Physically, each instance of 'c-table' would have attributes including the following: * class-instance pair for the class to which the instance is bound * size of the bound class * number of instances of the bound class held in array * pointer to an array of instances of the bound class It would be assumed that any class a c-table instance is bound to would have as its first attribute a cell-sized value, which can be construed as a unique number, or a string hash value - it's up to the programmer to decide which. Has anyone implemented such a beast in FICL yet? If so, would you be willing to share your code? If not, would anyone like to contribute ideas/desires for auch a 'data table' class? Cheers David |
From: <jws...@at...> - 2001-12-07 01:04:08
|
BTW - you can get a decent (30-50%) speed-up by setting FICL_ROBUST to 0. This removes a lot of stack checking code. -- ======================== joh...@al... > Hi Billy, > > BT> You give the ficl code -- what was the C code? What was the C compiler? > BT> Just curiosity. > > I didn't include the C code because I though people would assume it's > something like the code below. Compiler was gcc over Cygwin. Also, the > FICL code was run on Windows native FICL. > > #include <stdlib.h> > #include <stdio.h> > int fib(int n); > main(int argc, char *argv[]) > { > int n; > if (argc != 2) > exit(1); > n = atoi(argv[1]); > printf("fib(%d) = %d\n", n, fib(n)); > } > > int fib(int n) > { > if (n < 3) > return 1; > else > return fib(n-1) + fib(n-2); > } > > >>In C, fib(42) took 10.25 secs to calculate on a T-bird 750. > >>In FICL, it took 547 seconds, a speed degradation factor of 53. > > BT> A bad difference, but not out of my expectations. ficl is not only > BT> insulated from the machine, it's also not optimized at all. A little > BT> peephole optimization could probably double performance -- but it's doubtful > BT> that it'd be worth the effort. > > >>FICL is abundantly fast enough for user interface stuff and basic > >>scripting things, but for any substantial calculations or manipulation > >>of data, it has a performance issue. > >>Luckily, though, it's brainlessly easy and convenient to write FICL > >>words in C and do all the heavy crunching in C. > > BT> And this is why. Most FICL apps almost certainly do just this, and making > BT> ficl's compiler smarter would also make it bigger. For ficl's main > BT> purposes, small is best. For my app, I'm choosing ficl over lua entirely > BT> for a tiny size advantage. > > Yes - FICL allows a lot of functionality to be packed into a small > size. Important, given that I've just recently ported FICL to a PDA > running Windows CE 2.11, and added wrappers for the FLTK GUI library, > therefore allowing the FICL code to generate and run GUIs on linux, > windows and windows CE . > > -- > Regards, > David mailto:da...@re... > > Defend your freedom of online speech > http://freeweb.sf.net > > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: 2.6 > > mQCPAzvXs9kBbgEEANHr7tHODruDgqTDPjODXSaq2I+EGsGvyZR3g+s5VyrlF2fH > ftChHHhsQUK5nDzafSLvDg5ctMnIb/aeEN3HT2URfc2s3zyHHCvcWU0BKhiFjxl5 > 1mVm2ihf6Ld5koX8ECvXhVvWjP8vXqw4B0IUZ8nODlSExx7JsEsMt0+QelfBABEB > AAG0JERhdmlkIE1jTmFiIDxkYXZpZEByZWJpcnRoaW5nLmNvLm56PokAlQMFEDvX > s9lLDLdPkHpXwQEBCeAD/RVJ9nxGPDTSxaQLvDclN+N78aJFTxIlehc/XOK3QMgT > CnrUjdi42xwKIGvWMD4Mfd3K4SNj50QfvvddrE8MYpMPDYIWLB31/bisVWja7QXT > 3zMLh2dj2n52GjGM9xFtJoXGM8oOxrODteBSh5fx5PNqvMpj5Zq9J7jC23WZKDj0 > =VHBU > -----END PGP PUBLIC KEY BLOCK----- > > > > _______________________________________________ > Ficl-developers mailing list > Fic...@li... > https://lists.sourceforge.net/lists/listinfo/ficl-developers |
From: David M. <da...@re...> - 2001-12-06 21:36:11
|
Hi Billy, BT> You give the ficl code -- what was the C code? What was the C compiler? BT> Just curiosity. I didn't include the C code because I though people would assume it's something like the code below. Compiler was gcc over Cygwin. Also, the FICL code was run on Windows native FICL. #include <stdlib.h> #include <stdio.h> int fib(int n); main(int argc, char *argv[]) { int n; if (argc != 2) exit(1); n = atoi(argv[1]); printf("fib(%d) = %d\n", n, fib(n)); } int fib(int n) { if (n < 3) return 1; else return fib(n-1) + fib(n-2); } >>In C, fib(42) took 10.25 secs to calculate on a T-bird 750. >>In FICL, it took 547 seconds, a speed degradation factor of 53. BT> A bad difference, but not out of my expectations. ficl is not only BT> insulated from the machine, it's also not optimized at all. A little BT> peephole optimization could probably double performance -- but it's doubtful BT> that it'd be worth the effort. >>FICL is abundantly fast enough for user interface stuff and basic >>scripting things, but for any substantial calculations or manipulation >>of data, it has a performance issue. >>Luckily, though, it's brainlessly easy and convenient to write FICL >>words in C and do all the heavy crunching in C. BT> And this is why. Most FICL apps almost certainly do just this, and making BT> ficl's compiler smarter would also make it bigger. For ficl's main BT> purposes, small is best. For my app, I'm choosing ficl over lua entirely BT> for a tiny size advantage. Yes - FICL allows a lot of functionality to be packed into a small size. Important, given that I've just recently ported FICL to a PDA running Windows CE 2.11, and added wrappers for the FLTK GUI library, therefore allowing the FICL code to generate and run GUIs on linux, windows and windows CE . -- Regards, David mailto:da...@re... Defend your freedom of online speech http://freeweb.sf.net -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCPAzvXs9kBbgEEANHr7tHODruDgqTDPjODXSaq2I+EGsGvyZR3g+s5VyrlF2fH ftChHHhsQUK5nDzafSLvDg5ctMnIb/aeEN3HT2URfc2s3zyHHCvcWU0BKhiFjxl5 1mVm2ihf6Ld5koX8ECvXhVvWjP8vXqw4B0IUZ8nODlSExx7JsEsMt0+QelfBABEB AAG0JERhdmlkIE1jTmFiIDxkYXZpZEByZWJpcnRoaW5nLmNvLm56PokAlQMFEDvX s9lLDLdPkHpXwQEBCeAD/RVJ9nxGPDTSxaQLvDclN+N78aJFTxIlehc/XOK3QMgT CnrUjdi42xwKIGvWMD4Mfd3K4SNj50QfvvddrE8MYpMPDYIWLB31/bisVWja7QXT 3zMLh2dj2n52GjGM9xFtJoXGM8oOxrODteBSh5fx5PNqvMpj5Zq9J7jC23WZKDj0 =VHBU -----END PGP PUBLIC KEY BLOCK----- |
From: David M. <da...@re...> - 2001-12-06 03:06:59
|
Hi all, I just ran a speed comparison of ficl versus C. The program used was a standard fibbonacci series. : fib dup 3 < if drop 1 else 1- dup recurse swap 1- recurse + endif ; In C, fib(42) took 10.25 secs to calculate on a T-bird 750. In FICL, it took 547 seconds, a speed degradation factor of 53. FICL is abundantly fast enough for user interface stuff and basic scripting things, but for any substantial calculations or manipulation of data, it has a performance issue. Luckily, though, it's brainlessly easy and convenient to write FICL words in C and do all the heavy crunching in C. Cheers David |
From: Robert V. G. <rcv...@op...> - 2001-12-01 03:30:40
|
Hi, Thankyou for Ficl.=20 I to have been interfacing ficl to another language -- Delphi. I wanted a easy word oriented macro language (at least on the surface) = so users could add modify and change the order of various equipment = control functions. I looked a delphi script and python and came to the = conclusion that they we to structured for the non programmer. I then = remembered a encounter with forth many years ago. After a google search = found that it was active and after finding ficl I turned the forth = engine into a windows dll and can call it delphi. Still lots to do but I = am sure the idea will be successful.=20 Robert Van Gemet ----------------------------------------- unit FORTH; interface uses Windows, SysUtils; type CallBackFuncType =3D procedure(msg: PChar); stdcall; var InitFicl: function: integer stdcall; TermFicl: procedure stdcall; EvalFicl: function(_in: PChar): integer stdcall; ExecFicl: function(_in: PChar): integer stdcall; GetFiclText: function: PChar stdcall; FiclSetCallBack: procedure(fun: CALLBACKFUNCTYPE) stdcall; var DLLLoaded: Boolean =3D False; implementation var SaveExit: pointer; DLLHandle: THandle; ErrorMode: Integer; procedure NewExit; far; begin ExitProc :=3D SaveExit; FreeLibrary(DLLHandle) end; procedure LoadDLL; var dll: string; begin if DLLLoaded then Exit; ErrorMode :=3D SetErrorMode($8000{SEM_NoOpenFileErrorBox}); dll :=3D ExtractFilePath(ParamStr(0))+'FORTH.DLL'; DLLHandle :=3D LoadLibrary(pchar(dll)); if DLLHandle >=3D 32 then begin DLLLoaded :=3D True; SaveExit :=3D ExitProc; ExitProc :=3D @NewExit; @InitFicl :=3D GetProcAddress(DLLHandle,'InitFicl'); @TermFicl :=3D GetProcAddress(DLLHandle,'TermFicl'); @EvalFicl :=3D GetProcAddress(DLLHandle,'EvalFicl'); @ExecFicl :=3D GetProcAddress(DLLHandle,'ExecFicl'); @GetFiclText :=3D GetProcAddress(DLLHandle,'GetFiclText'); @FiclSetCallBack :=3D GetProcAddress(DLLHandle,'FiclSetCallBack'); Assert(@InitFicl <> nil); Assert(@TermFicl <> nil); Assert(@EvalFicl <> nil); Assert(@ExecFicl <> nil); Assert(@FiclSetCallBack <> nil); end else begin DLLLoaded :=3D False; end; SetErrorMode(ErrorMode) end; initialization begin LoadDLL; end; end. |
From: Michel P. <mi...@zo...> - 2001-12-01 00:07:30
|
Here's the source for an Python extesion module that embeds ficl in python. Here's a quick example of it's usage: import ficl sys = ficl.sys() vm = sys.vm() def testEvaluate(self): vm.evaluate(""" : foo 10 0 do i drop loop ;""") vm.evaluate('foo') assert vm.depth() == 0 vm.evaluate('42') assert vm.depth() == 1 assert vm.popi() == 42 It has an INSTALL file that I hope is helpful, if you figure out how to werk it on windows let me know. http://www.zope.org/Members/michel/pyficl-0-1.tgz -Michel |
From: john s. <joh...@al...> - 2001-11-30 21:52:14
|
That's what the pExtend or context pointer is for. Please use pVM->pExtend - I'm getting rid of context because they are both for the same purpose. - John At 11/30/01 11:29 AM, Michel Pelletier wrote: >The output function doesn't maintain any state, so I'm not sure how I >can associate an output file (which is a pointer to a python object) >with the output of a Ficl VM. Here's my code: > >typedef struct { > PyObject_HEAD > FICL_VM *ficl_vm; > PyObject *out_file; >} FiclVMObject; > >static FiclVMObject * >newFiclVMObject(PyObject *arg) >{ > FiclVMObject *self; > PyObject *sys; > PyObject *d; > PyObject *outf; > > self = PyObject_New(FiclVMObject, &FiclVM_Type); > if (self == NULL) > return NULL; > > self->ficl_vm = ficlNewVM(my_system); > > /* Bind the output to sys.stdout */ > > sys = PyImport_ImportModule("sys"); > d = PyModule_GetDict(sys); > outf = PyDict_GetItemString(d, "stdout"); > Py_INCREF(outf); > self->out_file = outf; > > /* Still need to figure out how to write Ficl output to file */ > > return self; >} > >This works fine, but I don't see how any output function that is passed >to self->ficl_vm can be told about self->out_file. Is this what the >FICL_VM->context is for? > >-Michel > >_______________________________________________ >Ficl-developers mailing list >Fic...@li... >https://lists.sourceforge.net/lists/listinfo/ficl-developers John Sadler - joh...@al... T 650-595-4954 F 603-687-2885 C 415-271-6795 |
From: john s. <joh...@al...> - 2001-11-30 21:50:26
|
Michel - subclass is an alias for "--> sub" They should behave identically - object --> my-class and object subclass my-class do the same thing - John At 11/30/01 08:58 AM, you wrote: >john sadler wrote: > > > > > > >Is there a primer somewhere on wrapping C structs? > > > > There is, and I've just revised it - please take a look at > > http://ficl.sourceforge.net/ficl_oop.html > > and let me know if it answers your questions. > >It does, the Ficl object model is quite nice, and very much like the >underlying Python type model. They should map well. > >The only confusing thing I found was that all your exsamples use >'subclass' when the prose talks about 'sub'. I prefer subclass which >also apears to be the one that works. ;) > >-Michel John Sadler - joh...@al... T 650-595-4954 F 603-687-2885 C 415-271-6795 |
From: Michel P. <mi...@zo...> - 2001-11-30 19:28:41
|
The output function doesn't maintain any state, so I'm not sure how I can associate an output file (which is a pointer to a python object) with the output of a Ficl VM. Here's my code: typedef struct { PyObject_HEAD FICL_VM *ficl_vm; PyObject *out_file; } FiclVMObject; static FiclVMObject * newFiclVMObject(PyObject *arg) { FiclVMObject *self; PyObject *sys; PyObject *d; PyObject *outf; self = PyObject_New(FiclVMObject, &FiclVM_Type); if (self == NULL) return NULL; self->ficl_vm = ficlNewVM(my_system); /* Bind the output to sys.stdout */ sys = PyImport_ImportModule("sys"); d = PyModule_GetDict(sys); outf = PyDict_GetItemString(d, "stdout"); Py_INCREF(outf); self->out_file = outf; /* Still need to figure out how to write Ficl output to file */ return self; } This works fine, but I don't see how any output function that is passed to self->ficl_vm can be told about self->out_file. Is this what the FICL_VM->context is for? -Michel |
From: Michel P. <mi...@zo...> - 2001-11-30 16:57:15
|
john sadler wrote: > > > >Is there a primer somewhere on wrapping C structs? > > There is, and I've just revised it - please take a look at > http://ficl.sourceforge.net/ficl_oop.html > and let me know if it answers your questions. It does, the Ficl object model is quite nice, and very much like the underlying Python type model. They should map well. The only confusing thing I found was that all your exsamples use 'subclass' when the prose talks about 'sub'. I prefer subclass which also apears to be the one that works. ;) -Michel |
From: john s. <joh...@al...> - 2001-11-30 04:41:35
|
Michel - At 11/29/01 07:52 PM, Michel Pelletier wrote: >NP, BTW, embedding Ficl in Python is cool! Check out this Python module >that actually runs! <snip> Cool - I will. >The result? The Ficl loop takes 1.68 seconds, the Python loop takes >5.39 seconds. Ficl might just turn out to be a nice "inline assembly >language" for Python. Ficl is extremly easy to embed, I'm not really >even a C programmer and I did this in about four hours. Stay tuned - We are in the process of speeding Ficl's execution speed significantly, so it will benchmark even faster, >Is there a primer somewhere on wrapping C structs? There is, and I've just revised it - please take a look at http://ficl.sourceforge.net/ficl_oop.html and let me know if it answers your questions. John Sadler - joh...@al... T 650-595-4954 F 603-687-2885 C 415-271-6795 |
From: Bob D. <bo...@dr...> - 2001-11-30 04:26:53
|
11/29/2001 11:03:30 PM, Michel Pelletier <mi...@zo...> wrote: >This is awesome, Python is my favorite language and Forth was my first! >Seeing the two of them together is strangely pleasing. ;) That's about how I feel about it, although I think that my first language was APL. Not that this means I'd like to see APL embedded in Python. Ficl embedded in APL OTOH -- that would certainly make one's head spin. :-) >john sadler suggested that to me earlier and it works great. I'll >probably spend a few more hours on this tommorow and checked into a CVS >that others can have access too if you think you want to help add Ficl >to Python. ;) Let me know. You're right -- this is a strangely appealing project. Such coolness should be rewarded -- maybe I should buy your book instead of just using the PDF, I sprung for the two Beehive books :-) --Bob |
From: Michel P. <mi...@zo...> - 2001-11-30 04:02:38
|
Bob Drzyzgula wrote: > > 11/29/2001 9:08:51 PM, Michel Pelletier <mi...@zo...> wrote: > > >The current fun little thing I"m working on is embedding ficl in > >Python. > > How very cool. Will we soon be able to do ficl scripting in Zope? Yep, actually that works right now if you wanted to use it from External Methods or a Zope python product and all you cared about was passing integers into and out of forth. See my other email about working on getting other Python types in and out. This is awesome, Python is my favorite language and Forth was my first! Seeing the two of them together is strangely pleasing. ;) > Can you send me a copy of your stuff when it gets close to working? Uhm.. let me work on the packaging a bit more and I'll get it to you. > The only thing I notice right off the bat is that LVALUEtoCELL expects at least a long, > and you're handing it an int. This will of course only work if int and long are the same > length on your platform. Wouldn't declaring x a long make this clearer? Sounds good to me. Works too. > Also, if the int type is already a long on your system, I'd personally rather see just > > i = PyInt_FromLong(c.i); > > But now I'm probably just being picky. john sadler suggested that to me earlier and it works great. I'll probably spend a few more hours on this tommorow and checked into a CVS that others can have access too if you think you want to help add Ficl to Python. ;) -Michel |
From: Michel P. <mi...@zo...> - 2001-11-30 03:51:37
|
john sadler wrote: > > Michel - > > It looks like your cast is wrong. Try this: > c = vmPop(self->ficl_vm); > i = PyInt_FromLong(c.i); > Default promotion from int to long of the c.i parameter should keep the > compiler happy. Otherwise > try > i = PyInt_FromLong((long)(c.i)); > Your original code is casting the _address_ of c into a long, so you get > insane results. That works great! > HTH, and thanks for using Ficl! NP, BTW, embedding Ficl in Python is cool! Check out this Python module that actually runs! """ import ficl from time import time vm = ficl.vm() vm.evaluate(''' : forth_test ( n -- ) 100 0 do 100 0 do 100 0 do i j + + loop loop loop ; ''') current = time() vm.pushInt(0) vm.evaluate('forth_test') elapsed = time() - current print "Value is %s and took %s" % (vm.popInt(), elapsed) current = time() total = 0 for x in range(100): for y in range(100): for z in range(100): total = total + y + z elapsed = time() - current print "Value is %s and took %s" % (total, elapsed) """ The result? The Ficl loop takes 1.68 seconds, the Python loop takes 5.39 seconds. Ficl might just turn out to be a nice "inline assembly language" for Python. Ficl is extremly easy to embed, I'm not really even a C programmer and I did this in about four hours. My next step is to create better Ficl->Python communication than just integers. I'd like to be able to exchange any basic python type and equivalent Ficl types. Which brings me to my next question. ;) The Ficl docs say that C structs can be wrapped with Ficl classes. This is exactly what I need, as all Python built-in types start out as C structs. I'd like to take a standard Python struct, like the definition for the 'int' type: typedef struct { PyObject_HEAD long ob_ival; } PyIntObject; and wrap it with a Ficl class that defines a pseduo-Python like interface to the struct so that I can pass Python objects into Ficl and work with them in Ficl, and then pass them back. Is there a primer somewhere on wrapping C structs? Thanks! -Michel > - John > > At 11/29/01 06:08 PM, you wrote: > >I never saw my last message come to the list, so for anyone who was > >thinking of answering it don't bother, I figured out my problem. If you > >didn't see it than don't worry about it. > > > >The current fun little thing I"m working on is embedding ficl in > >Python. I have it working pretty well at the moment, I can create vms > >and evalute python strings containing forth code, and I can also push > >integers onto the stack from python, but I can't figure out how to pop > >them. That's my question. I have these two C functions: > > > >static PyObject * > >FiclVM_pushint(FiclVMObject *self, PyObject *args) > >{ > > int x; > > if (!PyArg_ParseTuple(args, "i:pushInt", &x)) > > return NULL; > > vmPush(self->ficl_vm, LVALUEtoCELL(x)); > > Py_INCREF(Py_None); > > return Py_None; > >} > > > > > >static PyObject * > >FiclVM_popint(FiclVMObject *self, PyObject *args) > >{ > > CELL c; > > PyObject *i; > > if (!PyArg_ParseTuple(args, ":pushInt")) > > return NULL; > > c = vmPop(self->ficl_vm); > > i = PyInt_FromLong((long)&c); > > Py_INCREF(i); > > return i; > >} > > > >The first function works fine and pushes the right integer onto the > >Forth stack. The second function does return a valid python integer but > >when I push '5' I get '-1758473533' or whatever back. How can I turn > >'c' into the right integer value? PyInt_FromLong expects a long value. > > > >Thanks, > > > >-Michel > > > >_______________________________________________ > >Ficl-developers mailing list > >Fic...@li... > >https://lists.sourceforge.net/lists/listinfo/ficl-developers > > John Sadler - joh...@al... > T 650-595-4954 F 603-687-2885 C 415-271-6795 |
From: Bob D. <bo...@dr...> - 2001-11-30 03:46:11
|
11/29/2001 9:08:51 PM, Michel Pelletier <mi...@zo...> wrote: >The current fun little thing I"m working on is embedding ficl in >Python. How very cool. Will we soon be able to do ficl scripting in Zope? Can you send me a copy of your stuff when it gets close to working? > I have it working pretty well at the moment, I can create vms >and evalute python strings containing forth code, and I can also push >integers onto the stack from python, but I can't figure out how to pop >them. That's my question. I have these two C functions: >static PyObject * >FiclVM_pushint(FiclVMObject *self, PyObject *args) >{ > int x; > if (!PyArg_ParseTuple(args, "i:pushInt", &x)) > return NULL; > vmPush(self->ficl_vm, LVALUEtoCELL(x)); > Py_INCREF(Py_None); > return Py_None; >} The only thing I notice right off the bat is that LVALUEtoCELL expects at least a long, and you're handing it an int. This will of course only work if int and long are the same length on your platform. Wouldn't declaring x a long make this clearer? Perhaps using unambiguous types such as int32_t, or more directly-relevent types such as FICL_INT, would be better? >static PyObject * >FiclVM_popint(FiclVMObject *self, PyObject *args) >{ > CELL c; > PyObject *i; > if (!PyArg_ParseTuple(args, ":pushInt")) > return NULL; > c = vmPop(self->ficl_vm); > i = PyInt_FromLong((long)&c); > Py_INCREF(i); > return i; >} I don't think that you want to take the address of c here :-) Quoting http://www.python.org/doc/current/api/intObjects.html : PyObject* PyInt_FromLong(long ival) : Return value: New reference. : Creates a new integer object with a value of ival. Perhaps you meant &c->i ? In any event, unless sizeof(long) = sizeof(float) = sizeof(void *) = sizeof(void (*)(void)) on your platform, beware of alignment issues if you just use the cell union without a member reference. Also, if the int type is already a long on your system, I'd personally rather see just i = PyInt_FromLong(c.i); But now I'm probably just being picky. >The first function works fine and pushes the right integer onto the >Forth stack. The second function does return a valid python integer but >when I push '5' I get '-1758473533' or whatever back. Yes, addresses can be quite large numbers... :-) > How can I turn >'c' into the right integer value? PyInt_FromLong expects a long value. Feed it the value rather than the address? :-) >Thanks, No problem. >-Michel > >_______________________________________________ >Ficl-developers mailing list >Fic...@li... >https://lists.sourceforge.net/lists/listinfo/ficl-developers > > |
From: Michel P. <mi...@zo...> - 2001-11-30 02:40:01
|
You can ignore this, I fixed it. Thanks, -Michel Michel Pelletier wrote: > > Ficl looks pretty cool. Gots a embedding ficl question. I'm embedding > a ficl vm into Python extension module. The stub module currently works > like this: > > $ python > >>> import ficl > >>> v = ficl.vm() > >>> v > <FiclVM object at 0x80cbcd8> > >>> > > When the module ficl (which is written in C) is imported, a .so file is > dynamicly loaded. The C function that gets called looks like this: > > DL_EXPORT(void) > initficl(void) > { > PyObject *module, *module_dict; > FICL_SYSTEM *fs; > > // do some Python initializations .... > > fs = ficlInitSystem(32000) > } > > This code compiles into ficl.so ( the "extention module") fine, but when > I want to import the 'ficl' module I get an error: > > >>> import ficl > Traceback (most recent call last): > File "<stdin>", line 1, in ? > ImportError: libficl.so.3.0.0: cannot load shared object file: No shuch > file or directory > >>> > > Python can't find libficl.so.3.0.0, which is right there in the 'ficl' > subdirectory, even when I put it right in the same directory as > ficl.so. Here's the gcc compile command: > > gcc -Ificl -c ficlmodule.c -o ficlmodule.o > gcc -shared ficlmodule.o -Lficl -lficl -o ficl.so > > Any tips? Thanks! Sorry I don't know much about building C. > > -Michel > > _______________________________________________ > Ficl-developers mailing list > Fic...@li... > https://lists.sourceforge.net/lists/listinfo/ficl-developers |
From: Michel P. <mi...@zo...> - 2001-11-30 02:07:56
|
I never saw my last message come to the list, so for anyone who was thinking of answering it don't bother, I figured out my problem. If you didn't see it than don't worry about it. The current fun little thing I"m working on is embedding ficl in Python. I have it working pretty well at the moment, I can create vms and evalute python strings containing forth code, and I can also push integers onto the stack from python, but I can't figure out how to pop them. That's my question. I have these two C functions: static PyObject * FiclVM_pushint(FiclVMObject *self, PyObject *args) { int x; if (!PyArg_ParseTuple(args, "i:pushInt", &x)) return NULL; vmPush(self->ficl_vm, LVALUEtoCELL(x)); Py_INCREF(Py_None); return Py_None; } static PyObject * FiclVM_popint(FiclVMObject *self, PyObject *args) { CELL c; PyObject *i; if (!PyArg_ParseTuple(args, ":pushInt")) return NULL; c = vmPop(self->ficl_vm); i = PyInt_FromLong((long)&c); Py_INCREF(i); return i; } The first function works fine and pushes the right integer onto the Forth stack. The second function does return a valid python integer but when I push '5' I get '-1758473533' or whatever back. How can I turn 'c' into the right integer value? PyInt_FromLong expects a long value. Thanks, -Michel |
From: Michel P. <mi...@zo...> - 2001-11-30 00:44:07
|
Ficl looks pretty cool. Gots a embedding ficl question. I'm embedding a ficl vm into Python extension module. The stub module currently works like this: $ python >>> import ficl >>> v = ficl.vm() >>> v <FiclVM object at 0x80cbcd8> >>> When the module ficl (which is written in C) is imported, a .so file is dynamicly loaded. The C function that gets called looks like this: DL_EXPORT(void) initficl(void) { PyObject *module, *module_dict; FICL_SYSTEM *fs; // do some Python initializations .... fs = ficlInitSystem(32000) } This code compiles into ficl.so ( the "extention module") fine, but when I want to import the 'ficl' module I get an error: >>> import ficl Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: libficl.so.3.0.0: cannot load shared object file: No shuch file or directory >>> Python can't find libficl.so.3.0.0, which is right there in the 'ficl' subdirectory, even when I put it right in the same directory as ficl.so. Here's the gcc compile command: gcc -Ificl -c ficlmodule.c -o ficlmodule.o gcc -shared ficlmodule.o -Lficl -lficl -o ficl.so Any tips? Thanks! Sorry I don't know much about building C. -Michel |
From: David M. <da...@re...> - 2001-11-28 22:29:13
|
Hi john, js> I _do_ like it. A couple things I'd like to try to improve: js> 1. As implemented, all conditionals are executed for every pass through the js> switch, even if js> one matches early. I think I can add a simple trick that gets around that js> problem. Not too severe a problem, because: 1) The conditionals are getting executed, but the user code between each 'case'...'break' pair is not executed unless there's a match. So the implementation as it stands is working fine. 2) As it is, it would not be noticeably slower than a chain of 'if...endif' or 'if...else...endif' statements that people would have to use if 'switch' isn't available. 3) I'd advise against any strategy which executes the user code inside a matching conditional then jumps to the end of the switch. Even 'C' doesn't do that. Example: variable var1 variable var2 variable n ... [some calculations which alter var1, var2 and/or n] n @ switch 0 case some user code break 1 case some user code break var1 @ case some user code break var2 @ case some user code break endswitch As you can see from this example, a programmer may deliberately want case statements which are not mutually exclusive, which is accepted practice in 'C'. If you implement a dropout at the end of executing a matching case, the code will fail. If you want to implement mutual exclusivity (can be desirable for speed reasons), I'd advise a separate word, say, 'switch-ex'. David |
From: David M. <da...@re...> - 2001-11-26 20:12:22
|
js> David - js> It this related to ficl? js> - John >>The '@.' sequence is failing to terminate the handling of '@' format >>characters. <snip> That previous message was intended for the FLTK dev group, not FICL. Apologies for my mis-addressing it, and for the resultant noise on this list. FICL and FLTK are both FLA's beginning with 'F' - well, that's my excuse :) David |
From: john s. <joh...@al...> - 2001-11-26 17:00:35
|
That's pretty much how it's done. If you're doing a lot of indirect execution, you could make a table of XTs, or you could make a defining word that factors the common code... : noop ; \ doo-nothing word to default an execution vector.. : vector create ['] noop , does> @ execute ; : !vector ' >body : tovector ' >body ! ; \ now try this... : noop2 ." nothing happens " cr ; vector v v ' noop2 tovector v v At 11/22/01 03:59 PM, you wrote: >Hi FICL, > > I note that the oo classes have the 'suspend class' construct which > permits mutual references between classes. > > But I notice that outside oo, there's no 'is' word for binding a > ':noname' body with an earlier defined word. > > Does anyone have any ideas about forward-declaring words? > > I've thought up something that's pretty disgusting: > > variable word1-xt > variable word2-xt > > : word1 word1-xt @ execute ; > : word2 word2-xt @ execute ; > > : word1-body > ... > \ call to word2 > word2 > ... > ; ' word1-body word1-xt ! > > : word2-body > ... > \ call to word1 > word1 > ... > ; ' word2-body word2-xt ! > > Any improvements on this? > >-- >Regards, > David mailto:da...@re... > > > >_______________________________________________ >Ficl-developers mailing list >Fic...@li... >https://lists.sourceforge.net/lists/listinfo/ficl-developers John Sadler - joh...@al... T 650-595-4954 F 603-687-2885 C 415-271-6795 |
From: john s. <joh...@al...> - 2001-11-26 16:11:59
|
David - You need to create an 'init' method for your class that takes the ( c-addr u -- ) of the filename off the stack and uses it to create the instance as you wish. Right now there's no easy way to override a metaclass method, unfortunately. But I did think enough to provide a hook in the form of 'init' to do this sort of thing. Alternatively, you could define a 'fromstring' method that does the setup that you want and call it explicitly on a new instance. This has the advantage that it does not change the expected signature of 'init' ( 2:this -- ). If you create a 'new' method in c-inifile, it does not have the effect you want. Since methods of c-inifile describe the behavior of c-inifile *instances*, you are not overriding metaclass's 'new'. There are certainly times when it would be good to be able to extend metaclass in various ways. - John At 11/22/01 08:38 PM, you wrote: >Hi, > >I want to build a class with a constructor that takes and argument and >acts on that argument. > >For example: > > s" file.ini" c-inifile --> new ( "filename" -- class inst ) > >c-inifile is a class governing *.ini files, whose 'new' constructor >method takes a filename argument, parses the file's contents, and >returns a class-instance pair on the stack. > >If I simply define a method 'new' within the class def, will execution >of this method result in an automatic call to the 'metaclass' 'new' >method? > >Or will I need to have something like > > postpone super --> new > >within c-inifile's 'new' method? And in this case, will 'super --> >new' create an instance of the correct size? > >Thoughts? >David > > > >_______________________________________________ >Ficl-developers mailing list >Fic...@li... >https://lists.sourceforge.net/lists/listinfo/ficl-developers John Sadler - joh...@al... T 650-595-4954 F 603-687-2885 C 415-271-6795 |
From: David M. <da...@re...> - 2001-11-26 09:08:21
|
Hi Ficl-developers, At end of this message is an implementation of a 'C'-like 'switch' statement that works in FICL. It uses the return stack, so that any user code inside 'switch' statement blocks doesn't have to allow for extraneous data stack values. Try it - I'm sure you'll like it -- Regards, David mailto:da...@re... CODE FOLLOWS ------------------------------------------------ \ switch \ ( test -- r:0 r:test ) \ \ Starts a 'switch' statement block \ \ This implementation of switch is quite similar to C, except that: \ 1) Every case statement must end with a 'break' \ 2) There is no ability to omit the 'break' and 'fall through' to \ subsequent case statements \ 3) The whole 'switch' statement block must end with 'endswitch' \ \ Example: \ \ : fred ( n -- ) \ switch \ 0 case \ ." zero" cr \ break \ 1 case \ ." one" cr \ break \ default \ ." something else" cr \ break \ endswitch \ ; : switch ( val -- r:0 r:val ) postpone false postpone >r postpone >r ; immediate \ case \ ( r:flag r:test x -- r:flag` r:test ) \ \ A branch of a 'switch' statement. See 'switch' : case ( r:flag r:val -- val flag ) postpone r@ postpone = ( r:flag r:val =if ) postpone if ( r:flag r:val ) postpone r> ( r:flag val ) postpone r> ( val flag ) postpone drop ( val ) postpone true ( val true ) postpone >r ( r:true val ) postpone >r ( r:true r:val ) ; immediate \ break \ ( r:flag r:test -- r:flag r:test ) \ \ Terminates a 'case' branch of a 'switch' statement block \ See 'switch' : break ( -- ) postpone endif ( r:flag r:test ) ; immediate \ default \ ( -- ) \ \ Forms the 'default' branch of a 'switch' statement block. \ Encloses code that only gets executed if none of the prior 'case'..'break' \ branches were executed. : default ( r:flag r:val -- r:flag r:val ) postpone r> ( r:flag val ) postpone r@ ( r:flag val flag ) postpone swap ( r:flag flag val ) postpone >r ( r:flag r:val flag ) postpone 0= ( r:flag r:val ~flag ) postpone if ( r:flag r:val ) ; immediate \ endswitch \ ( r:flag r:test -- ) \ \ Terminates a 'switch' statement block. \ See 'switch'. : endswitch postpone r> postpone drop postpone r> postpone drop ; immediate |
From: David M. <da...@re...> - 2001-11-25 02:45:08
|
Hi all, The '@.' sequence is failing to terminate the handling of '@' format characters. For example, the statement: pBrowser->add("@b@i@.bold iitalic fr...@so...", NULL); produces: bold italic fred Even if I user format_char(c) to change the format character, '@' characters are still getting processed. As a workaround, I'm using a method addfmt(char *fmt, char *txt) which replaces the first '@' in txt (if any) with '@@'. Regards David |