Re: A Minimal PicoLisp DB/GUI Application, Importing twice
On Fri, Jan 16, 2015 at 08:30:47AM +0100, Alexander Burger wrote: Then something else must be wrong. The expression Sorry! My fault!! Jon was in the unlucky situation of having installed an intermediate version, where the behavior of '+IdxFold' was just in the process of small modifications. With the current version 3.1.9.3 everything works as expected :) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Importing
Hi Jon, (de importAddr (F) (let (Cnt 0 L NIL) (in F (while (setq L (split (line) ^I)) (dbSync) (let Obj (request '(+Prs) 'nm (pack (car L))) (put Obj 'adr (pack (cadr L))) (put Obj 'em (pack (caddr L))) (put Obj 'tel (pack (cadddr L))) (put Obj 'dob (format (pack (get L 5 ) (commit 'upd) (inc 'Cnt) ) ) (prinl Lines read: Cnt) ) ) OK, fine. Looks good :) If I do the import twice from the same file, then I get duplicates of each address in the DB. This is strange, and should not be the case. Are you sure? The 'request' prevents that, as long as the names 'nm' are different. One of the addresses in my DB is Veien 1, Byen”. If I search for 1 in Address, I get no match, but if I search for 9 in Address, I get a match. Why this difference? I tried to explain that in a previous mail. Only substrings of a minimal length of 3 characters make sense to be searched, because that is the shortest substring written into the index. Searching for a single character may or may not return something, depending if it happens that a substring starts with it. 999 and are in the index. If my DB containes very many addresses, say more than 1000, then a search could easily match lot more than the 12 that can be displayed at one time in this app. Yes, then you may scroll down in the chart. If the number of matches also was quite big, then I think it would have been nice to see this number down by the back- and forth-buttons at the bottom. Is it easy to get hold of this number? Not in general. As I said, the search is incremenetal. 1000 is not much, I have a million in some databases. Searching through all of them just to obtain the count of matches is not feasible. So QueryChart searches only as many as is given by the chart, and then continues to fetch the next single line, or the next page of 12 lines. How many addresses do you think this simple app can handle, without operations (search, update) getting very slow? More than 100.000? I’m just curious. No limit. It won't get slow even with 100 millions, for the above reasons. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Importing
Hi Alex, Now I have got this import thing working. I added the following code at the end of the minDbGui.l file: # To import from tab-separated file, use: (importAddr myAddrDB.csv) (de importAddr (F) (let (Cnt 0 L NIL) (in F (while (setq L (split (line) ^I)) (dbSync) (let Obj (request '(+Prs) 'nm (pack (car L))) (put Obj 'adr (pack (cadr L))) (put Obj 'em (pack (caddr L))) (put Obj 'tel (pack (cadddr L))) (put Obj 'dob (format (pack (get L 5 ) (commit 'upd) (inc 'Cnt) ) ) (prinl Lines read: Cnt) ) ) If I do the import twice from the same file, then I get duplicates of each address in the DB. That’s not a big problem, but if it is possible to prevent duplicated names by doing something simple, that could be something I’d like to do. Another observation: One of the addresses in my DB is Veien 1, Byen”. If I search for 1 in Address, I get no match, but if I search for 9 in Address, I get a match. Why this difference? If my DB containes very many addresses, say more than 1000, then a search could easily match lot more than the 12 that can be displayed at one time in this app. If the number of matches also was quite big, then I think it would have been nice to see this number down by the back- and forth-buttons at the bottom. Is it easy to get hold of this number? How many addresses do you think this simple app can handle, without operations (search, update) getting very slow? More than 100.000? I’m just curious. /Jon On 15. Jan, 2015, at 07:57, Alexander Burger a...@software-lab.de wrote: On Wed, Jan 14, 2015 at 05:54:17PM +0100, Alexander Burger wrote: A simple example would be (in myAdrDB.csv (while (split (line) ^I) (dbSync) (let Obj (request '(+Prs) 'nm (pack (car L))) (put Obj 'adr (pack (cadr L))) (put Obj ...) ... ) (commit 'upd) ) ) Not correct of course. Better: (use L (in myAdrDB.csv (while (setq L (split (line) ^I)) (dbSync) ... L ... -- -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
RE: A Minimal PicoLisp DB/GUI Application, Importing twice
Hi Alex, From: picolisp@software-lab.de picolisp@software-lab.de on behalf of Alexander Burger a...@software-lab.de Sent: 15 January 2015 16:42 To: picolisp@software-lab.de Subject: Re: A Minimal PicoLisp DB/GUI Application, Importing Hi Jon, (de importAddr (F) (let (Cnt 0 L NIL) (in F (while (setq L (split (line) ^I)) (dbSync) (let Obj (request '(+Prs) 'nm (pack (car L))) (put Obj 'adr (pack (cadr L))) (put Obj 'em (pack (caddr L))) (put Obj 'tel (pack (cadddr L))) (put Obj 'dob (format (pack (get L 5 ) (commit 'upd) (inc 'Cnt) ) ) (prinl Lines read: Cnt) ) ) OK, fine. Looks good :) If I do the import twice from the same file, then I get duplicates of each address in the DB. This is strange, and should not be the case. Are you sure? The 'request' prevents that, as long as the names 'nm' are different. ... ♪♫ Alex Yes, I have now repeated my experiment from scratch, importing same file twice. I get duplicates. Here is my myAddrDB.csv file, just replace the vertical bars with tabs: Per|Veien 1|p...@no.no|11223344|712582 Pål|Veien 2|p...@no.no|11223345|712583 Espen Askeladd|Veien 3|es...@no.no|11223346|712584 Ola Normann|Veien 4||11223347|712585 Here is the dumped results: (obj (+Prs) (1 . 7) dob 712584 tel 11223346 em es...@no.no adr Veien 3 nm Espen Askeladd ) (obj (+Prs) (1 . 19) dob 712584 tel 11223346 em es...@no.no adr Veien 3 nm Espen Askeladd ) (obj (+Prs) (1 . 12) dob 712585 tel 11223347 adr Veien 4 nm Ola Normann ) (obj (+Prs) (1 . 26) dob 712585 tel 11223347 adr Veien 4 nm Ola Normann ) (obj (+Prs) (1 . 2) dob 712582 tel 11223344 em p...@no.no adr Veien 1 nm Per ) (obj (+Prs) (1 . 13) dob 712582 tel 11223344 em p...@no.no adr Veien 1 nm Per ) (obj (+Prs) (1 . 6) dob 712583 tel 11223345 em p...@no.no adr Veien 2 nm Pål ) (obj (+Prs) (1 . 18) dob 712583 tel 11223345 em p...@no.no adr Veien 2 nm Pål ) (commit) /JonPԔ � j)mX��� ��zV�u�.n7�
Re: A Minimal PicoLisp DB/GUI Application, Importing twice
Hi Jon, Yes, I have now repeated my experiment from scratch, importing same file twice. I get duplicates. Here is my myAddrDB.csv file, just replace the vertical bars with tabs: Per|Veien 1|p...@no.no|11223344|712582 Pål|Veien 2|p...@no.no|11223345|712583 Espen Askeladd|Veien 3|es...@no.no|11223346|712584 Ola Normann|Veien 4||11223347|712585 Then something else must be wrong. The expression (request '(+Prs) 'nm (pack (car L))) re-uses an existing object with that name. BTW, if you want the combination of name and address to be unique, you could call (request '(+Prs) 'nm (pack (car L)) 'adr (pack (cadr L)) ) Anyway, I imported your data several times, and always end up with 4 objects in the DB. Perhaps these objects remained from previous experiments? Did you start with an empty DB? Please remove the adr.db file once, and try again. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Importing
Hi Jon, maybe this script will be of help: https://bitbucket.org/hsarvell/ext/src/tip/sqlimport.l?at=default It's very crude but it is trying to handle the SQL - PicoDB conversion through the constraint that you have to first run it on table A if A is referenced in table B, and then run it again on table B, that way you can create the +Ref on import. On Thu, Jan 15, 2015 at 7:57 AM, Alexander Burger a...@software-lab.de wrote: On Wed, Jan 14, 2015 at 05:54:17PM +0100, Alexander Burger wrote: A simple example would be (in myAdrDB.csv (while (split (line) ^I) (dbSync) (let Obj (request '(+Prs) 'nm (pack (car L))) (put Obj 'adr (pack (cadr L))) (put Obj ...) ... ) (commit 'upd) ) ) Not correct of course. Better: (use L (in myAdrDB.csv (while (setq L (split (line) ^I)) (dbSync) ... L ... -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Telephone field
On 2015/01/14-14:37, Luis P. Mendes wrote: Hi, 2015-01-14 12:09 GMT+00:00 Alexander Burger a...@software-lab.de: I see. So Norway has different systematics with telephone numbers. I don't understand them, though. In Germany we have the rule that both 0049 123 456 and +49 123 456 are the same as 0123 456. The 00 to + conversion is of no problem, but the 0 leading local or domestic numbers seems to be a feature of some countries, but not of others. There are even more variations though, including for international calling code: from Australia: 0011 + country code + area code + ... from USA: 011 + country code + area code + ... -- Rowan Thorpe PGP fingerprint: BB0A 0787 C0EE BDD8 7F97 3D30 49F2 13A5 265D CCBD There is a great difference between worry and concern. A worried person sees a problem, and a concerned person solves a problem. - Harold Stephens -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Importing
Hi Alex, On 13. Jan, 2015, at 15:37, Alexander Burger a...@software-lab.de wrote: . . . How difficult would it be to create export and import functions, e.g. to and from tab-separated files? This could be separate utilities, i.e. not a part of the GUI. That's very easy. There is a report mechanism in PicoLisp. You find examples for that in the demo application in the app/ directory. The 'csv' function is called there, e.g. in sales.l and inventory.l. Same with import. You can import CSV or XML (an example for the latter is in http://picolisp.com/wiki/?osmgeodata). But each case is different, depending on the specialities of the format at hand. If you just want an import/export, you could use 'dump'. (load @lib/too.l) (out adrDump.l (dump (db nm +Prs @@)) ) You can then do (load adrDump.l) to read the data back. . . . ♪♫ Alex I’ve got the dump and load working, but I have not yet figured out how to use the 'csv’ function for import from a file (I took a look at sales.l and “inventory.l”). Maybe it would be just as easy to generate an adrDump.l file from a CSV file? The only thing that I don’t understand about the adrDump.l file, is the dotted pair after the (+Prs), as here: (obj (+Prs) (1 . 27) Can that dotted pair be generated according to some simple rule? /Jon
Re: A Minimal PicoLisp DB/GUI Application, Telephone field
Hi, 2015-01-14 12:09 GMT+00:00 Alexander Burger a...@software-lab.de: I see. So Norway has different systematics with telephone numbers. I don't understand them, though. In Germany we have the rule that both 0049 123 456 and +49 123 456 are the same as 0123 456. The 00 to + conversion is of no problem, but the 0 leading local or domestic numbers seems to be a feature of some countries, but not of others. Luis -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Telephone field
Hi Alex, On 14. Jan, 2015, at 13:09, Alexander Burger a...@software-lab.de wrote: Hi Jon, I don’t quite get this. I have done as you suggested, (locale NO no) and leading 0, so I can now enter a phone number as 099887766. You say it will be stored internally with leading 47 instead of that 0, but Right. You see that if you look directly into the DB. when I put the mouse over that phone-pencil icon, it seems that tel:099887766 is what will be used (and that’s also the href I see in the inspector). ... If I try to dial 022852804 from my mobile, I get number not in use. I see. So Norway has different systematics with telephone numbers. I don't understand them, though. In Germany we have the rule that both 0049 123 456 and +49 123 456 are the same as 0123 456. A number without a leading zero is a local number (within the same city, but that's almost obsolete these days as you can take your number with you when you move or change your provider, so you can't rely on that). The '+TelField' (based on the functions 'telStr' and 'expTel') handles this. What are the exact rules for Norway? And how can we handle this flexibly? ♪♫ Alex — I think this page describes Norwegian telephone numbers quite well: http://en.wikipedia.org/wiki/Telephone_numbers_in_Norway It also seems that the Danish numbers are somewhat similar: http://en.wikipedia.org/wiki/Telephone_numbers_in_Denmark I may not be the right person to say how we can handle this flexibly. ;-) I don’t know if it can be of any help, but here is Google’s common Java, C++ and JavaScript library for parsing, formatting, storing and validating international phone numbers: https://github.com/googlei18n/libphonenumber /Jon
Re: A Minimal PicoLisp DB/GUI Application, Importing
On Wed, Jan 14, 2015 at 05:54:17PM +0100, Alexander Burger wrote: A simple example would be (in myAdrDB.csv (while (split (line) ^I) (dbSync) (let Obj (request '(+Prs) 'nm (pack (car L))) (put Obj 'adr (pack (cadr L))) (put Obj ...) ... ) (commit 'upd) ) ) Not correct of course. Better: (use L (in myAdrDB.csv (while (setq L (split (line) ^I)) (dbSync) ... L ... -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Telephone field
Hi Jon, Luis, Rowan, thanks! I see that this problem is non-trivial. We need to extend the localization files loc/??.l Probably some functional expression or pattern needs to be stored there, in addition to (or as a replacement of) the country code '*CtryCode'. Perhaps the Google library gives the necessary information. I'll take a look asap. Any further input welcome! ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Importing
Hi Jon, I’ve got the dump and load working, but I have not yet figured out how to use the 'csv’ function for import from a file (I took a look at The 'csv' function can only generate the CSV file (TAB-separated data). It is not suitable for import. To import a CSV file, you need to write proper code depending on the data and the given situation. There are thousand possibilities of input formats, character sets, type and order of data. A simple example would be (in myAdrDB.csv (while (split (line) ^I) (dbSync) (let Obj (request '(+Prs) 'nm (pack (car L))) (put Obj 'adr (pack (cadr L))) (put Obj ...) ... ) (commit 'upd) ) ) understand about the adrDump.l file, is the dotted pair after the (+Prs), as here: (obj (+Prs) (1 . 27) This is the object ID encoded as a dotted pair (see the 'id' function). 'dump' is actually overkill for this simple address DB. It tries to find a unique key for each object it dumps, so that references to this object from other objects can be properly resolved. The +Prs objects in the address DB don't have a unique key. And even the object ID is not needed, because there are no references (+Link or +Joint) from other objects. So for this simple case, you can simply ignore the dotted pair. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Telephone field
Isn't this a non-issue, simply enter and store all numbers regardless of location with country code + number without leading zero, eg 4912345678? Will work for all countries everywhere, I never store numbers without the country code in my mobile nowadays and always works regardless if I'm in said country or not. On Wed, Jan 14, 2015 at 5:23 PM, Alexander Burger a...@software-lab.de wrote: Hi Jon, Luis, Rowan, thanks! I see that this problem is non-trivial. We need to extend the localization files loc/??.l Probably some functional expression or pattern needs to be stored there, in addition to (or as a replacement of) the country code '*CtryCode'. Perhaps the Google library gives the necessary information. I'll take a look asap. Any further input welcome! ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Telephone field
On Wed, Jan 14, 2015 at 05:52:02PM +0100, Henrik Sarvell wrote: Isn't this a non-issue, simply enter and store all numbers regardless of location with country code + number without leading zero, eg 4912345678? Yes, as I said, simply use +TextField instead of +TelField. However, local customers will complain if they have to handle such unwieldy numbers :) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Telephone field
Hi Jon, I don’t quite get this. I have done as you suggested, (locale NO no) and leading 0, so I can now enter a phone number as 099887766. You say it will be stored internally with leading 47 instead of that 0, but Right. You see that if you look directly into the DB. when I put the mouse over that phone-pencil icon, it seems that tel:099887766 is what will be used (and that’s also the href I see in the inspector). ... If I try to dial 022852804 from my mobile, I get number not in use. I see. So Norway has different systematics with telephone numbers. I don't understand them, though. In Germany we have the rule that both 0049 123 456 and +49 123 456 are the same as 0123 456. A number without a leading zero is a local number (within the same city, but that's almost obsolete these days as you can take your number with you when you move or change your provider, so you can't rely on that). The '+TelField' (based on the functions 'telStr' and 'expTel') handles this. What are the exact rules for Norway? And how can we handle this flexibly? ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Telephone field
On Wed, Jan 14, 2015 at 01:09:12PM +0100, Alexander Burger wrote: The '+TelField' (based on the functions 'telStr' and 'expTel') handles this. What are the exact rules for Norway? And how can we handle this flexibly? Alternatively, of course, you could replace '+TelField' with '+TextField'. Then the GUI won't do anything with the telephone numbers. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Search popup puzzle
Hi Jon, I would like the Telephone field to accept 8-digit numbers, which is common in Norway. At the moment I have to prefix with +47, otherwise I get Bad phone number format. You should change the line in the 'main' function (locale UK) to (locale NO no) Then, entering a number 0123 456 will show in the GUI with a leading zero, but will be stored internally as 47 123 456. Telephone numbers are stored internally always in this normalized format, to allow a uniform search. How difficult would it be to create export and import functions, e.g. to and from tab-separated files? This could be separate utilities, i.e. not a part of the GUI. That's very easy. There is a report mechanism in PicoLisp. You find examples for that in the demo application in the app/ directory. The 'csv' function is called there, e.g. in sales.l and inventory.l. Same with import. You can import CSV or XML (an example for the latter is in http://picolisp.com/wiki/?osmgeodata). But each case is different, depending on the specialities of the format at hand. If you just want an import/export, you could use 'dump'. (load @lib/too.l) (out adrDump.l (dump (db nm +Prs @@)) ) You can then do (load adrDump.l) to read the data back. How about sorting the names case-insensitive? Now Willy comes before von. For a Norwegian, it would also be nice if Å came after Ø, at least in a more serious application than this. I’m just curious. ;-) The search in a QueryChart doesn't come sorted at all. The reason is that this is an incremental search, finding things according to the search criteria (by searching all search keys in parallel). To be able to sort the results, you would need to first select *all* of them, and in a non-trivial application this may be too expensive. To get sorted output, a report again is the standard way to go. I have lots of examples, but unfortunately they are not public ... ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Search popup puzzle
Hi Alex,
Thanks. A few more questions:
I would like the Telephone field to accept 8-digit numbers, which is common in
Norway. At the moment I have to prefix with +47, otherwise I get Bad phone
number format.
How difficult would it be to create export and import functions, e.g. to and
from tab-separated files? This could be separate utilities, i.e. not a part of
the GUI.
How about sorting the names case-insensitive? Now Willy comes before von.
For a Norwegian, it would also be nice if Å came after Ø, at least in a more
serious application than this. I’m just curious. ;-)
/Jon
On 13. Jan, 2015, at 13:42, Alexander Burger a...@software-lab.de wrote:
Hi Jon,
When I’m typing in one of the search fields (Name or Address), a box
with possible matches pops up, but quite often there are names/addresses
missing in this box, and I haven’t been able to find a pattern in this.
If I type a (single) j, k, l, e, i or s, then my name comes up, but not
if I type just o, n or r. Do you know why?
Yes. The 'nm' relation in the DB model
(rel nm (+Sn +IdxFold +String))
uses two index prefixes:
1. +Sn for the soundex algorithm. It stores a condensed and unified
pattern in the DB index tree. In case of e.g. Jon Kleiser this
is JNSLSR. This pattern is used for tolerant searches.
2. +IdxFold applies the 'fold' function the whole name, and stores it
(i.e. jonkleiser) in the index. Then it splits the name on
blanks, 'fold's the fragments, and stores substrings of these
fragments.
But: The substrings are generated only up to a maximal length of three.
This is to avoid storing lots of single- or double-letter tokens - which
are not meaningful to search - in the index.
Thus, jon is stored, but not on or n.
If you dump the index, you'll see what's there:
: (scan '(nm . +Prs))
(JNSLSR {2} . T) {2}
(eiser {2}) {2}
(iser {2}) {2}
(jonkleiser . {2}) {2}
(kleiser {2}) {2}
(leiser {2}) {2}
(ser {2}) {2}
Thus, when you type in the search field, this index is accessed. Typing
iser or only ser will find something, but o, n or r won't.
♪♫ Alex
PԔ � j)mX��� ��zV�u�.n7�
Re: A Minimal PicoLisp DB/GUI Application, Search popup puzzle
Hi Jon,
When I’m typing in one of the search fields (Name or Address), a box
with possible matches pops up, but quite often there are names/addresses
missing in this box, and I haven’t been able to find a pattern in this.
If I type a (single) j, k, l, e, i or s, then my name comes up, but not
if I type just o, n or r. Do you know why?
Yes. The 'nm' relation in the DB model
(rel nm (+Sn +IdxFold +String))
uses two index prefixes:
1. +Sn for the soundex algorithm. It stores a condensed and unified
pattern in the DB index tree. In case of e.g. Jon Kleiser this
is JNSLSR. This pattern is used for tolerant searches.
2. +IdxFold applies the 'fold' function the whole name, and stores it
(i.e. jonkleiser) in the index. Then it splits the name on
blanks, 'fold's the fragments, and stores substrings of these
fragments.
But: The substrings are generated only up to a maximal length of three.
This is to avoid storing lots of single- or double-letter tokens - which
are not meaningful to search - in the index.
Thus, jon is stored, but not on or n.
If you dump the index, you'll see what's there:
: (scan '(nm . +Prs))
(JNSLSR {2} . T) {2}
(eiser {2}) {2}
(iser {2}) {2}
(jonkleiser . {2}) {2}
(kleiser {2}) {2}
(leiser {2}) {2}
(ser {2}) {2}
Thus, when you type in the search field, this index is accessed. Typing
iser or only ser will find something, but o, n or r won't.
♪♫ Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application
On 2015/01/12-08:34, Alexander Burger wrote: Hi all, perhaps this is useful: A Minimal PicoLisp DB/GUI Application http://picolisp.com/wiki/?minDbGui ♪♫ Alex Such clear, precise and informative little gems like this are why I am a fan of picolisp (the language and the implementation). FWIW: I am subscribed to *many* mailing lists, but I think the picolisp list is the only one I actually read every single message from. -- Rowan Thorpe PGP fingerprint: BB0A 0787 C0EE BDD8 7F97 3D30 49F2 13A5 265D CCBD There is a great difference between worry and concern. A worried person sees a problem, and a concerned person solves a problem. - Harold Stephens -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application
It's a really good example. On January 12, 2015 8:34:08 AM CET, Alexander Burger a...@software-lab.de wrote: Hi all, perhaps this is useful: A Minimal PicoLisp DB/GUI Application http://picolisp.com/wiki/?minDbGui ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
Re: A Minimal PicoLisp DB/GUI Application
Hi Alex! That's great, thanks! Best regards, Mansur 12.01.2015 12:34, Alexander Burger пишет: Hi all, perhaps this is useful: A Minimal PicoLisp DB/GUI Application http://picolisp.com/wiki/?minDbGui ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
