March 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] NeoJSON Mappings

by Sven Van Caekenberghe

On 18 Mar 2013, at 19:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > NeoJSON is actually two things: a standard JSON parser and encoder using roughly Dictionary for maps and some regular Collection for lists. That sentence is incomplete. Make that: NeoJSON is actually two things: first, a standard JSON parser and encoder using roughly Dictionary for maps and some regular Collection for lists, and second a mapping system on top of that. Additionally, while writing, the key message sent to each object is #neoJsonOn: neoJSONWriter - you could also overwrite that, check the implementors. For reading, the key message is #readFrom: neoJSONReader sent to mappings (see #nextAs:). But I guess you already know all this. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 19, 2013

Re: [Pharo-users] Unicode in Smalltalk

by Sven Van Caekenberghe

Ben, On 19 Mar 2013, at 00:41, Ben Coman <btc(a)openInWorld.com> wrote: > Sven Van Caekenberghe wrote: >> On 18 Mar 2013, at 17:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On Mar 18, 2013, at 5:26 PM, LogiqueWerks <grshiplett(a)gmail.com> wrote: >>> >>> >>>> so-desu ... >>>> >>>> Clicked in don't show message again box ... >>>> >>>> But by then I was looking at >>>> >>>> (encoding = 'utf-8') ifTrue: [^UTF8TextConverter]. >>>> (encoding = 'shiftjis' or: [ encoding = 'sjis' ]) >>>> as seen in JapaneseEnvironment>>systemConverterClass for X11 ... also looks >>>> a little fragile for lack of accessors yet X11Encoding is just such a >>>> class-side location for "utf8EncodingCode" or such like ... >>>> My other programming environment uses "utf8" as the string. Oi vey. Then >>>> there are the 'UTF-8' folks out there ... >>>> Is there a reason to avoid symbols here ? Or at least to refactor that >>>> >>>> () or: [] >>>> out and into X11Encoding ? >>>> >>>> That call at 2AM on a Sunday morning is Sooo often for similar issues that >>>> crept past code reviews ... or is this a lighter style that I am used to ? >>>> >>> code quality is very low for most of the old code baseâ¦ Improvements are always welcome. >>> >> >> Check out the ZnCharacterEncoder hierarchy for a much simpler, more modern implementation of UTF8 and some common byte encoders. > > Is that a candidate to move into core? It is permanently in the image. Pending community testing, feedback, improvement, extension, yes it could replace the others. It is currently used for the HTTP layer, but is fully functional for any stream: 'my-utf8-file.txt' asFileReference readStreamDo: [ :stream | stream binary. "remove the old stuff" (ZnCharacterReadStream on: stream) upToEnd ]. The key difference is that is works strictly from bytes to/from characters, not from character to/from character like the old ones. Sven >> It requires people fluent in all kinds of special spoken languages to help in moving things forward. >> >> What do we really need above UTF8 and some simple byte encoders ? >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >> >> > >

March 19, 2013

Re: [Pharo-users] Unicode in Smalltalk

by Ben Coman

Sven Van Caekenberghe wrote: > On 18 Mar 2013, at 17:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On Mar 18, 2013, at 5:26 PM, LogiqueWerks <grshiplett(a)gmail.com> wrote: >> >> >>> so-desu ... >>> >>> Clicked in don't show message again box ... >>> >>> But by then I was looking at >>> >>> (encoding = 'utf-8') >>> ifTrue: [^UTF8TextConverter]. >>> (encoding = 'shiftjis' or: [ encoding = 'sjis' ]) >>> >>> as seen in JapaneseEnvironment>>systemConverterClass for X11 ... also looks >>> a little fragile for lack of accessors yet X11Encoding is just such a >>> class-side location for "utf8EncodingCode" or such like ... >>> >>> My other programming environment uses "utf8" as the string. Oi vey. Then >>> there are the 'UTF-8' folks out there ... >>> >>> Is there a reason to avoid symbols here ? Or at least to refactor that >>> >>> () or: [] >>> >>> out and into X11Encoding ? >>> >>> That call at 2AM on a Sunday morning is Sooo often for similar issues that >>> crept past code reviews ... or is this a lighter style that I am used to ? >>> >> code quality is very low for most of the old code baseâ¦ >> Improvements are always welcome. >> > > Check out the ZnCharacterEncoder hierarchy for a much simpler, more modern implementation of UTF8 and some common byte encoders. > Is that a candidate to move into core? > It requires people fluent in all kinds of special spoken languages to help in moving things forward. > > What do we really need above UTF8 and some simple byte encoders ? > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

March 18, 2013

Re: [Pharo-users] [Esug-list] [ANN] Pharo 2.0

by Ben Coman

That is a really impressive amount of work. I really feel like I am betting on a good horse here - a young colt with some great years of racing ahead. A very small thing (a personal preference only if it does not align with your philosophy). You might you title that page "Pharo 2.0 Release Notes". Its just one industry convention that I am partial to and what I google for when I am looking for the history of some software. cheers -ben Benjamin wrote: > Note that this can also be found on our new issue tracker: https://pharo.fogbugz.com/default.asp?W6 > > Ben > > > On Mar 18, 2013, at 11:12 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> We are proud to announce the release of Pharo 2.0! >> >> You can find information about Pharo at: http://www.pharo-project.org >> >> About this release >> ------------------ >> All in all, there were over 1600 issues treated in the issue tracker >> and 1350 improvements integrated into 2.0. >> >> http://code.google.com/p/pharo/issues/list?can=1&q=Milestone%3D2.0+status%3… >> >> Read it again, yes 1350 is huge, take two minutes and have a look at the list of >> improvements! Now you got the feel of the effort. And this was a true community >> effort. It is possible because people worldwide helped! We want to deeply thank them. >> >> We want to thank Inria for its constant support, in particular for the salary of Igor >> Stasenko and Esteban Lorenzano, and for the help in the infrastructure. >> >> We have accomplished this huge task for a better system because we were together. Do not >> forget that we are working on a consortium to support our system: >> >> - http://consortium.pharo.org (for companies and organizations) >> - http://association.pharo.org (for individuals) >> >> Our goal is to build a system so that we can make a living with our creativity and >> programming skills. >> >> You can find information about Pharo on http://www.pharo-project.org. In particular, >> you may be interested in: >> >> - Joining us and getting help http://www.pharo-project.org/community >> - Getting the Pharo By Example book (available as a free PDF): http://www.pharobyexample.org >> - Watching the screencasts http://www.pharocasts.com >> - Reporting problems http://www.pharo-project.org/community/issue-tracking >> - Reading the forth coming book http://rmod.lille.inria.fr/pbe2 >> - Reading the Pharo vision document http://bit.ly/HNkEru >> >> Thanks a lot for your participation, energy and fun. >> >> -- The Pharo Team >> >> Summarized issues for 2.0 >> ================== >> >> UI >> --- >> >> - Spec >> - Widget enhancements >> - Layout improvements/cleanups >> - Keybindings >> - New icons (famfam) >> - Growl style notifications >> - Revamp progress bar >> >> Developer tools >> --------------- >> >> - Nautilus browser >> - Critics browser >> - Improved version diff browsing >> - Spotlight >> - Revamp Code Completion and smart chars >> - Interactive navigation using ctrl/cmd+click over classes/methods >> - Shout themes >> - Andreas profiler >> >> Networking >> ----------- >> >> - Update Zinc >> - Zodiac (SSL) >> >> System >> ------- >> >> - System Announcer >> - RPackage replacing PackageInfo >> - Command line tools / Headless mode >> - Native boost >> - Update Ring metamodel >> - Fuel serializer >> - Freetype fonts >> >> Kernel >> ------ >> >> - DateAndTime refactoring >> - Updated FileSystem and replaced FileDirectory >> >> VM >> -- >> >> - Latests cog builds >> - SSLPlugin >> - FilePlugin enhancements >> - SocketPlugin fixes >> - Included libraries: freetype2, cairo >> >> Cleanups >> ------------- >> >> - FileDirectory removed (replaced by FileSystem) >> - SmartRefStream and ReferenceStream removed (replaced by Fuel) >> - PackageInfo deprecated (replaced by RPackage) >> >> Other >> ------- >> >> - Zeroconf scripts >> - Continuous Integration for every aspect of our release process. >> >> Not all the changes are reported here, but this is to give you an impression, >> you can find better explanation here: https://code.google.com/p/pharo/wiki/ActionsInPharo20 >> >> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> > > >

March 18, 2013

Re: [Pharo-users] NeoJSON Mappings

by Esteban A. Maringolo

Hi Sven, 2013/3/18 Sven Van Caekenberghe-2 [via Smalltalk] > There is however a problem: the basic JSON spec is deliberately limited > and vague about certain aspects, and even non existing for other aspects > such as typing, references or cycles. There exist numerous ways to add > those > to JSON, some very complicated ones, often coming from statically typed > languages. Many of those kill the human readability/writability of JSON. > The > problem of how to encode a type or class in JSON across languages is > actually unsolved. That is why I decided not to implement any support for > that. > With NeoJSON mappings your are supposed to know upfront what types your > JSON represents/contains. This works fine in many cases but certainly not > all. In this case I know it. And I Just need the writter and not the reader, altough it might be useful in the future. > Circular references will always be a problem. > Structure sharing is extra complicated, it requires both reader and writer > support with an objet table. Yes, this happens with any serializer without global state or object table :) > STON, which is very similar but incompatible with JSON, has support for > all these aspects, right out of the box, no mapping required. If you do > not > have to interact with foreign systems, that is an option. In this case JSON is mandatory. The consumer of the data is a mobile device. The other alternative is, god forbid, XML, which isn't friendly in terms of bandwidth. > Support for one of the many semantics built on top of JSON will have to be > built by hand. Hopefully the mapping layer can help there. But like you > said: you'll have to play with custom mappings. The mapping system is > pretty > simple to understand. Yes, but sometimes I feel the need to be able to map instVars/accesors to encoder/decoders without having to use an schema (defined by a symbol). I haven't found the case where it is not an extra step. > PS: I also have to confess that although I am using NeoJSON in various > important projects myself, we usually stick with Dictionaries/Collections > without doing any mapping. Only in very specific cases do we actually > convert to specific Smalltalk objects. Same happens here so far, I produce JSON, and get JSON back, but then I manually pick the JSON values (deserialized as Dictionaries/Arrays) and assign them to my objects. I don't know what the guys from SmalltalkHub are using to serialize/deserialize JSON. Thanks for your support. I'll keep with using custom mappings for almost everything that references an object which isn't "simple" (string, dates, numbers, etc.). Best regards, -- Esteban. -- View this message in context: http://forum.world.st/NeoJSON-Mappings-tp4677077p4677222.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 18, 2013

Re: [Pharo-users] NeoJSON Mappings

by Sven Van Caekenberghe

Hello Esteban, On 18 Mar 2013, at 00:48, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi, > > I'm happily mapping my objects to JSON. But in order to reduce the payload > I'm looking for a way to map my objects differently depending on whether it > is the root object of the mapping or not. > > Let's say I have two classes with the following instvars between > parenthesis: > * ClassA(id, name) > * ClassB(id, classA) > > I'm using #neoJsonMapping: to define the mappings and (NeoJsonWriter > toString: classB) to get the JSON string. > > If in the Class B mappings I reference classA (by instVar or accessor) I get > the whole ClassA instance serialized as JSON. Which is not what I want. I'd > like to have only the id of classA. > > I know I can define a custom mapping using for:customDo: , but I'd like to > know if there is another way to do that. > > And this relates to another point, that is how to define a schema for a > whole hierarchy of objects. All my objects are descendant of a common > superclass. > > There is no way I can do the following on different levels: > super neoJsonMapping: mapper. > mapper for: self do: [:mapping | mapping mapInstVars: #(foo) ] > > Because on every call it overwrites the mapping for the schema of the > current call, ending up mapping only the instVar 'foo'. > > I can work my way around this by writing more, refactoring and so on. But I > would like to know if Sven or somebody else who uses NeoJSON have some > practice patterns that would like to share with the rest of us, mere > mortals. > > Best regards! > > > Esteban. Thanks for using NeoJSON and for giving feedback. NeoJSON is actually two things: a standard JSON parser and encoder using roughly Dictionary for maps and some regular Collection for lists. The mapping layer allows for an efficient conversion of JSON directly to and from Smalltalk objects, bypassing an intermediate Dictionary/Array representation. There is however a problem: the basic JSON spec is deliberately limited and vague about certain aspects, and even non existing for other aspects such as typing, references or cycles. There exist numerous ways to add those to JSON, some very complicated ones, often coming from statically typed languages. Many of those kill the human readability/writability of JSON. The problem of how to encode a type or class in JSON across languages is actually unsolved. That is why I decided not to implement any support for that. With NeoJSON mappings your are supposed to know upfront what types your JSON represents/contains. This works fine in many cases but certainly not all. Circular references will always be a problem. Structure sharing is extra complicated, it requires both reader and writer support with an objet table. STON, which is very similar but incompatible with JSON, has support for all these aspects, right out of the box, no mapping required. If you do not have to interact with foreign systems, that is an option. Support for one of the many semantics built on top of JSON will have to be built by hand. Hopefully the mapping layer can help there. But like you said: you'll have to play with custom mappings. The mapping system is pretty simple to understand. I know this is much help, but I hope it makes things a bit clearer. Regards, Sven PS: I also have to confess that although I am using NeoJSON in various important projects myself, we usually stick with Dictionaries/Collections without doing any mapping. Only in very specific cases do we actually convert to specific Smalltalk objects. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 18, 2013

Re: [Pharo-users] WebDav

by phil＠highoctane.be

Thx, Server that is. Phil 2013/3/18 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 18 Mar 2013, at 16:47, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> How would one implement WebDAV on a Pharo 2.0 image? >> >> I saw several projects for Squeak but wonder what the best approach would be. >> >> Phil > > Client or server ? > > WebDAV is basically HTTP with some extras. > > There exists some old client code in Zinc-WebDAV but that has not yet been ported to FS. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >

March 18, 2013

Re: [Pharo-users] Unicode in Smalltalk

by Sven Van Caekenberghe

On 18 Mar 2013, at 17:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: > On Mar 18, 2013, at 5:26 PM, LogiqueWerks <grshiplett(a)gmail.com> wrote: > >> so-desu ... >> >> Clicked in don't show message again box ... >> >> But by then I was looking at >> >> (encoding = 'utf-8') >> ifTrue: [^UTF8TextConverter]. >> (encoding = 'shiftjis' or: [ encoding = 'sjis' ]) >> >> as seen in JapaneseEnvironment>>systemConverterClass for X11 ... also looks >> a little fragile for lack of accessors yet X11Encoding is just such a >> class-side location for "utf8EncodingCode" or such like ... >> >> My other programming environment uses "utf8" as the string. Oi vey. Then >> there are the 'UTF-8' folks out there ... >> >> Is there a reason to avoid symbols here ? Or at least to refactor that >> >> () or: [] >> >> out and into X11Encoding ? >> >> That call at 2AM on a Sunday morning is Sooo often for similar issues that >> crept past code reviews ... or is this a lighter style that I am used to ? > > code quality is very low for most of the old code baseâ¦ > Improvements are always welcome. Check out the ZnCharacterEncoder hierarchy for a much simpler, more modern implementation of UTF8 and some common byte encoders. It requires people fluent in all kinds of special spoken languages to help in moving things forward. What do we really need above UTF8 and some simple byte encoders ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 18, 2013

Re: [Pharo-users] Unicode in Smalltalk

by Marcus Denker

On Mar 18, 2013, at 5:26 PM, LogiqueWerks <grshiplett(a)gmail.com> wrote: > so-desu ... > > Clicked in don't show message again box ... > > But by then I was looking at > > (encoding = 'utf-8') > ifTrue: [^UTF8TextConverter]. > (encoding = 'shiftjis' or: [ encoding = 'sjis' ]) > > as seen in JapaneseEnvironment>>systemConverterClass for X11 ... also looks > a little fragile for lack of accessors yet X11Encoding is just such a > class-side location for "utf8EncodingCode" or such like ... > > My other programming environment uses "utf8" as the string. Oi vey. Then > there are the 'UTF-8' folks out there ... > > Is there a reason to avoid symbols here ? Or at least to refactor that > > () or: [] > > out and into X11Encoding ? > > That call at 2AM on a Sunday morning is Sooo often for similar issues that > crept past code reviews ... or is this a lighter style that I am used to ? code quality is very low for most of the old code baseâ¦ Improvements are always welcome. Marcus

March 18, 2013

Re: [Pharo-users] Unicode in Smalltalk

by LogiqueWerks

so-desu ... Clicked in don't show message again box ... But by then I was looking at (encoding = 'utf-8') ifTrue: [^UTF8TextConverter]. (encoding = 'shiftjis' or: [ encoding = 'sjis' ]) as seen in JapaneseEnvironment>>systemConverterClass for X11 ... also looks a little fragile for lack of accessors yet X11Encoding is just such a class-side location for "utf8EncodingCode" or such like ... My other programming environment uses "utf8" as the string. Oi vey. Then there are the 'UTF-8' folks out there ... Is there a reason to avoid symbols here ? Or at least to refactor that () or: [] out and into X11Encoding ? That call at 2AM on a Sunday morning is Sooo often for similar issues that crept past code reviews ... or is this a lighter style that I am used to ? -- View this message in context: http://forum.world.st/Unicode-in-Smalltalk-tp4676821p4677188.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 18, 2013