June 2018 - Pharo-users - lists.pharo.org

Re: SQL Server

by orsayman

Ah, I have seen your message on SO. Sorry, I can't help more. Maybe someone knows how to install DBXTalk on pharo 6.1. Have you tried to contact the authors or the community (https://guillep.github.io/DBXTalk/contact.html) ? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 12, 2018

Re: SQL Server

by orsayman

I'm not an expert but have a look at DBXTalk <https://guillep.github.io/DBXTalk/garage/drivers.html> . If I understand correctly, it is able to connect to SQL Server. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 12, 2018

Re: [Pharo-users] Is it bad to have an order NeoJsonObject?

by Herbert VojÄÃk

Richard O'Keefe wrote on 12. 6. 2018 3:54: > > Herbert VojÄÃk > > âwrote " it is already part of the spec a few years already that > enumeration on the object keys MUST respect the order in which keys > were created". The JavaScript (ECMA-262) spec, not the JSON (ECMA 404) spec. The rest follows as described in my previous post.

June 12, 2018

Re: [Pharo-users] Macros?

by Richard O'Keefe

I've been reconstructing an old programming language. It originally had a very simple but awkward macro facility: if an identifier was declared as a macro, whenever it was called, it could inspect/consume as much of the remaining tokens as it wished and could splice other tokens in. On top of this a very nice "declarative" macro system was built, which I loved when I used it. Since my implementation is not yet self-hosting, I've been using higher-order functions instead, and the more I do this the less I want macros. You could think of the rewrite rules in VisualWorks as something resembling macros. Come to think of it, Lukas Renggli, Helvetia, ... found it! http://scg.unibe.ch/archive/phd/renggli-phd.pdf On 12 June 2018 at 12:10, Michael Forster <mike(a)forsterfamily.ca> wrote: > On Fri, May 25, 2018 at 10:12 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > On 25 May 2018 at 21:22, Debiller 777 <ozovozovozo202(a)gmail.com> wrote: > >> > >> Well, I've already asked about adding new literals to pharo or Smalltalk > >> in general, however this time I have a better idea: > >> macros. Can they be added? Because if I understand correctly they may be > >> the only way to do that. > > > > > > Can you provide an example how how you would use a macro? > > > > cheers -ben > > > > Late to the party, but I thought some might find it interesting to > look through the "macros vs. blocks" thread on the old Lightweight > Languages mailing list. Posts from Guy Steele Jr., Avi Bryant, Trevor > Blackwell (rewrote Graham's Yahoo Store in Smalltalk), and others: > > https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02060.html > > > Cheers, > > Mike > >

June 12, 2018

Re: [Pharo-users] Is it bad to have an order NeoJsonObject?

by Richard O'Keefe

Herbert VojÄÃk âwrote " it is already part of the spec a few years already that enumeration on the object keys MUST respect the order in which keys were created". I quoted two specs: json.org and the ECMA one. The current RFC for JSON is, I believe, RFC 8259, which says JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences. What this is saying is that some JSON libraries do preserve order and some do NOT. There is no "de facto" standard specifying order preservation. What's more, the language is warning you that if you rely on order, you should NOT expect your program to interoperate with anything else and it is your fault if it doesn't. If there is some other specification for JSON that requires order to be preserved, tell us where to find it. This is not about JavaScript. JSON is not strictly compatible with JavaScript anyway. Consider Python: >>> json.loads('{"a":1,"b":2}') {u'a': 1, u'b': 2} >>> json.loads('{"b":2,"a":1}') {u'a': 1, u'b': 2} âUsing JSON::Parse in Perl gives the same result; the order does not matter. I could go on all day listing JSON libraries, tools, and interfaces that either never preserve key order or make that an esoteric use- at-your-own-peril option. â When you are designing a protocol using JSON syntax, and you want an ordered association between keys and values, you can interoperably use something like { "__isOrderedObject__": true , "keys": ["a","b"] , "values": â[1, 2 ] } Just to repeat: if you can find any ISO, ECMA, ITU, or IETF specification that says key order should be preserved, let's hear about it. I have three JSON parsers I've written, and I want them to be right. Not like the brand X package that says it can sometimes fail to read back JSON that it wrote.

June 12, 2018

Re: [Pharo-users] Macros?

by Michael Forster

On Fri, May 25, 2018 at 10:12 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 25 May 2018 at 21:22, Debiller 777 <ozovozovozo202(a)gmail.com> wrote: >> >> Well, I've already asked about adding new literals to pharo or Smalltalk >> in general, however this time I have a better idea: >> macros. Can they be added? Because if I understand correctly they may be >> the only way to do that. > > > Can you provide an example how how you would use a macro? > > cheers -ben Late to the party, but I thought some might find it interesting to look through the "macros vs. blocks" thread on the old Lightweight Languages mailing list. Posts from Guy Steele Jr., Avi Bryant, Trevor Blackwell (rewrote Graham's Yahoo Store in Smalltalk), and others: https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02060.html Cheers, Mike

June 12, 2018

Re: [Pharo-users] Is it bad to have an order NeoJsonObject?

by Herbert VojÄÃk

Norbert Hartl wrote on 11. 6. 2018 23:38: > > > Am 11.06.2018 um 16:48 schrieb Richard O'Keefe <raoknz(a)gmail.com > <mailto:raoknz@gmail.com>>: > >> I'm really baffled here. >> Look at the definition at json.org <http://json.org>. >> >> â An object is an UNORDERED set of name/value pairs. >> >> Or look at ECMA-404, which json.org <http://json.org> points to. >> >> The JSON syntax does not impose any restrictions on >> the strings used as names ... and DOES NOT ASSIGN >> ANY SIGNIFICANCE TO THE ORDERING. >> >> When you say that "it is pretty clear that the order is >> important for that format" I fail to understand you. >> It is absolutely clear that by design the order is NOT >> important or even significant for JSON. >> >> JSON Pointer does not provide any way to refer to order >> in an "object": /2 applied to an object will look for >> the name "2" as a string. >> >> JSONPath does not provide any way to refer to order in >> an "object": [2] applied to an object will look for >> the name "2" as a string. >> >> JSON Schema does not provide any way to constrain or >> refer to order in an "object". >> >> As for databases, Postgres documentation says of JSONB >> that "Insignificant whitespace is discarded, and >> the order of object keys is not preserved." >> >> If you are communicating with someone else who is using >> pseudo-JSON that does attach semantics to the order of >> the name/value pairs, then of course you do whatever you >> have to in order to communicate successfully. Just don't >> think of it as JSON. If you have two programs whose >> protocol you control, again you can use JSON syntax with >> different semantics all you want. Just don't think of it >> as JSON. Heck, if it is important to you to distinguish >> between integer 1 and floating point 1.0, you can add >> your own semantics if you like, but *JSON* doesn't >> distinguish them. >> >> As for MongoDB, it works with BSON (which is richer than >> JSON. which is why "MongoDB Extended JSON exists), and >> does some seriously odd things, like regarding >> {} and {"a": null} as equal. (According to the 3.6 manual.) >> >> Do whatever you have to do to get the job done, >> but just remember that most JSON tools think they are >> dealing with *JSON*, not something else that looks >> like it but has different semantics, and can be relied >> on to preserve or respect *JSON* semantics, not some >> other semantics unknown to them. >> > It was not talked about JSON but about a content format that uses JSON > as its encoding. So if that format how poor it appears to use puts > significance to the ordering why you even start to argue? > Why care about JSON tools and talk about semantics because there is no > semantic in an encoding format. It is an encoding format of nested keys > and values and arrays. No key or value has special meaning. It is dumb > JSON. > You can use every JSON tool to read and destroy it. Like you can read a > binary file in a text editor apply newline conventions and destroy it. > What is the point here? I presume the point here is that, if you presume JSON is mostly used with JavaScript, then JSON _is_, in effect, keeping the order. If I am not mistaken, it is already part of the spec a few years already that enumeration on the object keys MUST respect the order in which keys were created, and JSON algorithm prescribes that keys are created in the order they are read when parsing, and should use the internal order of keys when stringifying. So, JSON is de facto preserving order, though de iure it is not. But the fact that is does it de facto, leads to creation of order-dependent services. Not saying this is correct per specs, not that it is correct from general design PoV, just that it happens because order preserving _is_ already there, so the code may end up using it, even unconsciously. This "JSON is in practice order-preserving" implementation artifact then leaks out when some protocols end up requiring it. Then other languages may feel the need to have this "industry standard" of order-preserving JSON to have as well. OP correct me if I am wrong. Herby > Norbert

June 11, 2018

Re: [Pharo-users] Is it bad to have an order NeoJsonObject?

by Norbert Hartl

> Am 11.06.2018 um 16:48 schrieb Richard O'Keefe <raoknz(a)gmail.com>: > > I'm really baffled here. > Look at the definition at json.org. > > â An object is an UNORDERED set of name/value pairs. > > Or look at ECMA-404, which json.org points to. > > The JSON syntax does not impose any restrictions on > the strings used as names ... and DOES NOT ASSIGN > ANY SIGNIFICANCE TO THE ORDERING. > > When you say that "it is pretty clear that the order is > important for that format" I fail to understand you. > It is absolutely clear that by design the order is NOT > important or even significant for JSON. > > JSON Pointer does not provide any way to refer to order > in an "object": /2 applied to an object will look for > the name "2" as a string. > > JSONPath does not provide any way to refer to order in > an "object": [2] applied to an object will look for > the name "2" as a string. > > JSON Schema does not provide any way to constrain or > refer to order in an "object". > > As for databases, Postgres documentation says of JSONB > that "Insignificant whitespace is discarded, and > the order of object keys is not preserved." > > If you are communicating with someone else who is using > pseudo-JSON that does attach semantics to the order of > the name/value pairs, then of course you do whatever you > have to in order to communicate successfully. Just don't > think of it as JSON. If you have two programs whose > protocol you control, again you can use JSON syntax with > different semantics all you want. Just don't think of it > as JSON. Heck, if it is important to you to distinguish > between integer 1 and floating point 1.0, you can add > your own semantics if you like, but *JSON* doesn't > distinguish them. > > As for MongoDB, it works with BSON (which is richer than > JSON. which is why "MongoDB Extended JSON exists), and > does some seriously odd things, like regarding > {} and {"a": null} as equal. (According to the 3.6 manual.) > > Do whatever you have to do to get the job done, > but just remember that most JSON tools think they are > dealing with *JSON*, not something else that looks > like it but has different semantics, and can be relied > on to preserve or respect *JSON* semantics, not some > other semantics unknown to them. > It was not talked about JSON but about a content format that uses JSON as its encoding. So if that format how poor it appears to use puts significance to the ordering why you even start to argue? Why care about JSON tools and talk about semantics because there is no semantic in an encoding format. It is an encoding format of nested keys and values and arrays. No key or value has special meaning. It is dumb JSON. You can use every JSON tool to read and destroy it. Like you can read a binary file in a text editor apply newline conventions and destroy it. What is the point here? Norbert

June 11, 2018

Re: [Pharo-users] [Pharo-dev] [Ann] Iceberg v1.1.0

by Guillermo Polito

On Mon, Jun 11, 2018 at 7:23 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Hi Guille, > > Thank you for the update. > Can this be installed in Pharo 6.1? How? > This is already in latest Pharo build. If you want to try it in a Pharo 6.1 (I recommend to do it in a clean image), you can follow the instructions in the README https://github.com/pharo-vcs/iceberg#for-pharo-61 Those instructions will unload iceberg and install the latest 1.* version > It was tested on Windows? > I did not do it personally, but I know Cyril is using it in windows successfully for a couple of months already. He's even using it to contribute to Pharo and Iceberg itself from windows. I'd like to have the tests running on windows, but for that we need OSSubprocess running on windows... (Or maybe depending on ProcessWrapper is a compromise solution?). If someone would like to help on that front, making use of ProcessWrapper in the tests should not be difficult (it was done before but that code rot because of the lack of CI in the past...) > > Cheers, > > HernÃ¡n > > > 2018-06-11 14:04 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > Time for the weekly Iceberg update. > > Thanks to all brave users, issue reporters and contributors :). > > > > Key changes: we have introduced some tag support, a new credential > manager > > to manage keys and passwords per host or repository, a new version of > tonel, > > and made a first step towards a simplified contribution to Iceberg by > > listing it as Pharo's repository. > > > > Enjoy, > > Guille in behalf of all Iceberg contributors > > > > Following, the detailed changes log. > > > > New Features > > #842 Adding Credentials Store > > #843 Update Tonel to 1.0.7 > > #823 Iceberg repository should be listed as Pharo's one > > #841 Basic tag support (#372) > > > > Infrastructure > > #787 Add Windows ci with Appveyor (not yet green!) > > > > Enhancements > > #827 Add package dialog has some glitches > > #833 replace #asIcon with #iconNamed: > > #832 Move Iceberg from MostUsedTools to Tools > > #830 Better handling of not github remote urls > > #825 Enhance Migrate to tonel commit message > > #637 Show tag version instead of "Detached HEAD" > > #829 migrate-versions-browser > > > > Bug Fixes > > #835 Compare file definitions by their binary uninterpreted content > > #838 Clone from incorrect github repository fails with DNU > > #826 Pushing to virgin repository raises a DNU > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 11, 2018

Re: [Pharo-users] [Pharo-dev] [Ann] Iceberg v1.1.0

by Peter UhnÃ¡k

> > tag support, a new credential manager to manage keys and passwords per > host or repository Thank you! I'm looking forward to playing with this next week. (and reporting issues :)) Peter On Mon, Jun 11, 2018 at 7:23 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Hi Guille, > > Thank you for the update. > Can this be installed in Pharo 6.1? How? > It was tested on Windows? > > Cheers, > > HernÃ¡n > > > 2018-06-11 14:04 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > Time for the weekly Iceberg update. > > Thanks to all brave users, issue reporters and contributors :). > > > > Key changes: we have introduced some tag support, a new credential > manager > > to manage keys and passwords per host or repository, a new version of > tonel, > > and made a first step towards a simplified contribution to Iceberg by > > listing it as Pharo's repository. > > > > Enjoy, > > Guille in behalf of all Iceberg contributors > > > > Following, the detailed changes log. > > > > New Features > > #842 Adding Credentials Store > > #843 Update Tonel to 1.0.7 > > #823 Iceberg repository should be listed as Pharo's one > > #841 Basic tag support (#372) > > > > Infrastructure > > #787 Add Windows ci with Appveyor (not yet green!) > > > > Enhancements > > #827 Add package dialog has some glitches > > #833 replace #asIcon with #iconNamed: > > #832 Move Iceberg from MostUsedTools to Tools > > #830 Better handling of not github remote urls > > #825 Enhance Migrate to tonel commit message > > #637 Show tag version instead of "Detached HEAD" > > #829 migrate-versions-browser > > > > Bug Fixes > > #835 Compare file definitions by their binary uninterpreted content > > #838 Clone from incorrect github repository fails with DNU > > #826 Pushing to virgin repository raises a DNU > >

June 11, 2018