Re: pgint.l
Hi Michael, yeah you right, i will do it in general list at first, thanks for advice. чт, 17 янв. 2019 г. в 19:22, Michel Pelletier : > Hi Abel, > > Great work, I'll give it a shot on pg 10 and 11 later today at work. As > for the mailing lists, I'd start with pgsql-general mailing list before the > -hackers list, the same core devs watch both lists so you'll get the same > high grade advice. They'll let you know if you should promote the issue to > -hackers. The main advantage is, you'll get many more eyeballs on -general > and it's more appropriate given it's not a core dev issue. > > -Michel > > On Wed, Jan 16, 2019 at 11:05 PM Abel Normand > wrote: > >> Thanks all for your suggestions, I will open respective issues for minor >> improvements. >> >> Also mmamkin connected with me directly and also suggested to use prefix >> "pg-" for whole library not only for public functions. I think that I >> probably should to use namespaces to hide private functions. It would be >> nice if someone would share with me best practice for using them bcs I >> still do not have deep understanding in their usage. >> >> There is also a "postgresql-hackers" mailing list where devs discuss not >> only DBMS development but also clients and adapters implementation. So I >> think I should to share lib with them also, it probably will draw some >> attention to language itself and devs from pg community will advice >> something. What you think? >> >> Thanks. >> *From:* r...@tamos.net >> *Sent:* 16 January 2019 16:04 >> *To:* picolisp@software-lab.de >> *Reply to:* picolisp@software-lab.de >> *Subject:* Re: pgint.l >> >> +1 for writing tests. >> +1 for using aw-‘s test harness. >> +1 for having a sane license. >> >> Huzzah! :) >> >> >> >> >> On Tue, 15 Jan 2019 21:11 +0300, Abel Normand wrote: >> > Hello everyone, >> > >> > I'm happy to announce that I released my small library to interfacing >> with >> > PostgreSQL -- https://gitlab.com/Abel-ze-Normand/pgint.l . I tried to >> keep >> > its implementation as simple as possible. >> > >> > I'm open to your suggestions for future improvements and your >> > contributions. >> > -- >> > Best regards, Nail >> >> -- С уважением, Наиль.
Re: pgint.l
Hi Abel, Great work, I'll give it a shot on pg 10 and 11 later today at work. As for the mailing lists, I'd start with pgsql-general mailing list before the -hackers list, the same core devs watch both lists so you'll get the same high grade advice. They'll let you know if you should promote the issue to -hackers. The main advantage is, you'll get many more eyeballs on -general and it's more appropriate given it's not a core dev issue. -Michel On Wed, Jan 16, 2019 at 11:05 PM Abel Normand wrote: > Thanks all for your suggestions, I will open respective issues for minor > improvements. > > Also mmamkin connected with me directly and also suggested to use prefix > "pg-" for whole library not only for public functions. I think that I > probably should to use namespaces to hide private functions. It would be > nice if someone would share with me best practice for using them bcs I > still do not have deep understanding in their usage. > > There is also a "postgresql-hackers" mailing list where devs discuss not > only DBMS development but also clients and adapters implementation. So I > think I should to share lib with them also, it probably will draw some > attention to language itself and devs from pg community will advice > something. What you think? > > Thanks. > *From:* r...@tamos.net > *Sent:* 16 January 2019 16:04 > *To:* picolisp@software-lab.de > *Reply to:* picolisp@software-lab.de > *Subject:* Re: pgint.l > > +1 for writing tests. > +1 for using aw-‘s test harness. > +1 for having a sane license. > > Huzzah! :) > > > > > On Tue, 15 Jan 2019 21:11 +0300, Abel Normand wrote: > > Hello everyone, > > > > I'm happy to announce that I released my small library to interfacing > with > > PostgreSQL -- https://gitlab.com/Abel-ze-Normand/pgint.l . I tried to > keep > > its implementation as simple as possible. > > > > I'm open to your suggestions for future improvements and your > > contributions. > > -- > > Best regards, Nail > >
Re: pgint.l
On Thu, Jan 17, 2019 at 04:29:17PM +0100, Danilo Kordic wrote: > IMHO (PicoLisp) Namespaces _are_ "name" prefixes, for example "pg~" > instead of "pg-". > > [de pg []] # Empty Namespace. > [de pg~sym ~...] No, they are not. "pg~" is not part of the name. For example, one symbol may be in several namespaces. This is not possible with name prefixes. Also, prefixes are part of the name and thus show up on string operations like 'chop'. With prefixes, you need to write them *always*, clobbering the source code. Also, you can with namespaces dynamically control the search order for a given name, which is not possible with prefixes. You may load the same source file in different namespaces, giving different behavior. > Unfortunately Namespaces are not Association Lists, or Property Lists. Why should they be? They would be too slow due to linear searches. > Therefore they can not be processed by predefined procedures. I must point > out that Namespace interface is not exposed (as PicoLisp procedures), like > "get" and so on for Property Lists!! It is exposed. A namespace is an index tree, you can access it with 'all'. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pgint.l
IMHO (PicoLisp) Namespaces _are_ "name" prefixes, for example "pg~" instead of "pg-". [de pg []] # Empty Namespace. [de pg~sym ~...] Unfortunately Namespaces are not Association Lists, or Property Lists. Therefore they can not be processed by predefined procedures. I must point out that Namespace interface is not exposed (as PicoLisp procedures), like "get" and so on for Property Lists!!
Re: pgint.l
Hi Abel, > Also mmamkin connected with me directly and also suggested to use prefix "pg-" > for whole library not only for public functions. I think that I probably > should to use namespaces to hide private functions. I would also recommend namespaces. > It would be nice if someone would share with me best practice for using them > bcs I still do not have deep understanding in their usage. There are some examples for namespaces in the PicoLisp distribution, in the libraries @lib/gis.l, @lib/android.l and @lib/vip.l. PilBox (https://software-lab.de/PilBox.tgz) also uses namespaces, it even depends on them, because it runs several apps alternatingly in the same PicoLisp process, including different database models. To see typical PilBox apps, look at the internet radio (https://software-lab.de/radio.zip), the bignum calculator (https://software-lab.de/calc.zip) or the general dummy demo (https://software-lab.de/demo.zip). In general, I use the following strategy: 1. *libraries* set their namespace at the very beginning (symbols 'newlib 'pico) or, if needed, (symbols 'mylib 'otherlib 'pico) This puts the new library in front of the search order, causing new symbols being created in that namespace. 2. *before* a symbol appears for the first time in the library source, a call to 'local' is recommended (local) foo or (local) [foo bar] Note that it is irrelevant where the symbol's value may be *defined* in the source. Important is where it is *read*. Namespaces care only about the visibility of symbols. Also note that the semantics of 'local' are a bit unusual. It takes no arguments, but *reads* the next expression in the current input stream so that all symbols contained in it are created newly (= interned) in this namespace. 3. In an *application* of that lib, I put it usually at the end, using the "set search order" syntax (symbols '(pico mylib)) or, if the app defines its own private namespace, I define it in the main (initially loaded) source (symbols 'demo 'gis 'pico 'android) and use the "set search order" syntax in all other files of the application if needed as (symbols '(demo gis pico android) (symbols '(radio pico android)) Such calls with a complete search order list may occur at various places, allowing you to fine-tune how symbols are read. Besides this, you can always access symbols from other namespaces (if they are not in the current search order (but that namespace is), or are shadowed by some symbol with the same name in a namespace earlier in the order) as mylib~foo I hope this helps for a first start. This whole namespace issue is not trivial, but a powerful tool to organize one's projects. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pgint.l
Thanks all for your suggestions, I will open respective issues for minor improvements. Also mmamkin connected with me directly and also suggested to use prefix "pg-" for whole library not only for public functions. I think that I probably should to use namespaces to hide private functions. It would be nice if someone would share with me best practice for using them bcs I still do not have deep understanding in their usage.There is also a "postgresql-hackers" mailing list where devs discuss not only DBMS development but also clients and adapters implementation. So I think I should to share lib with them also, it probably will draw some attention to language itself and devs from pg community will advice something. What you think?Thanks. From: r...@tamos.netSent: 16 January 2019 16:04To: picolisp@software-lab.deReply to: picolisp@software-lab.deSubject: Re: pgint.l +1 for writing tests. +1 for using aw-âs test harness. +1 for having a sane license. Huzzah! :) On Tue, 15 Jan 2019 21:11 +0300, Abel Normand wrote:> Hello everyone,>> I'm happy to announce that I released my small library to interfacing with> PostgreSQL -- https://gitlab.com/Abel-ze-Normand/pgint.l . I tried to keep> its implementation as simple as possible.>> I'm open to your suggestions for future improvements and your> contributions.> --> Best regards, Nail PÔ )m¢¢X¬¦Ê ·«zVuë.n7
Re: pgint.l
+1 for writing tests. +1 for using aw-‘s test harness. +1 for having a sane license. Huzzah! :) On Tue, 15 Jan 2019 21:11 +0300, Abel Normand wrote: > Hello everyone, > > I'm happy to announce that I released my small library to > interfacing with> PostgreSQL -- https://gitlab.com/Abel-ze-Normand/pgint.l . I > tried to keep> its implementation as simple as possible. > > I'm open to your suggestions for future improvements and your > contributions. > -- > Best regards, Nail
Re: pgint.l
> I'm happy to announce that I released my small library to interfacing with > PostgreSQL -- > https://gitlab.com/Abel-ze-Normand/pgint.l Tested: centos7 psql-9.2.xx -> works voidlinux psql-9.6.xx -> works (mike) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pgint.l
Thanks for your great job In my opinion: > 1) should I use PostgreSQL error codes and throw exceptions based on them? So you could probably write: > > (catch 'PGintegrityError ...) > (catch 'PGconstraintError ...) You should. It's a good practice to handle exceptions and this allow developers to control what happens and made robust soft > 2) probably I have to extract pg types <-> pico types translation to some kind of abstract table to support extensibility? So devs could add their own types to translation table without encoding-decoding by hand. I think it should be a nice feature but maybe not required
Re: pgint.l
Hi Alexander, thanks for your suggestion. I've completely forgot about (pass) behaviour, I would include this change in next patch. There are some questions that remained for me unanswered during development: 1) should I use PostgreSQL error codes and throw exceptions based on them? So you could probably write: (catch 'PGintegrityError ...) (catch 'PGconstraintError ...) And so forth. I did not find such error handling somewhat useful from my previous experience so I did not include it in initial release. 2) probably I have to extract pg types <-> pico types translation to some kind of abstract table to support extensibility? So devs could add their own types to translation table without encoding-decoding by hand. Thanks! On Tue, 15 Jan 2019, 21:50 Alexander Burger Hi Abel, > > > I'm happy to announce that I released my small library to interfacing > with > > PostgreSQL -- https://gitlab.com/Abel-ze-Normand/pgint.l . I tried to > keep > > its implementation as simple as possible. > > Cool, many thanks! > > I cannot comment on things PostgreSQL, as I never used it. But formally > the code > looks good. Just one minor optimization comes to mind: > > There are two cases where variable arguments are passed to another > function, > e.g. in: > >(de exec-libpq (Cmd RetTyp . @) > (apply native (conc (list "libpq.so" Cmd RetTyp) (rest))) ) > > As (list ...) and (rest) build new lists, just to pass them to 'apply', it > is > better to directly 'pass' the arguments to that function. With that we get: > >(de exec-libpq (Cmd RetTyp . @) > (pass native "libpq.so" Cmd RetTyp) ) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: pgint.l
Hi Abel, > I'm happy to announce that I released my small library to interfacing with > PostgreSQL -- https://gitlab.com/Abel-ze-Normand/pgint.l . I tried to keep > its implementation as simple as possible. Cool, many thanks! I cannot comment on things PostgreSQL, as I never used it. But formally the code looks good. Just one minor optimization comes to mind: There are two cases where variable arguments are passed to another function, e.g. in: (de exec-libpq (Cmd RetTyp . @) (apply native (conc (list "libpq.so" Cmd RetTyp) (rest))) ) As (list ...) and (rest) build new lists, just to pass them to 'apply', it is better to directly 'pass' the arguments to that function. With that we get: (de exec-libpq (Cmd RetTyp . @) (pass native "libpq.so" Cmd RetTyp) ) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
pgint.l
Hello everyone, I'm happy to announce that I released my small library to interfacing with PostgreSQL -- https://gitlab.com/Abel-ze-Normand/pgint.l . I tried to keep its implementation as simple as possible. I'm open to your suggestions for future improvements and your contributions. -- Best regards, Nail
