February 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40487 Home: https://github.com/pharo-project/pharo-core

Feb. 13, 2015

[pharo-project/pharo-core] 21e237: 40487

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 21e23792122a9d10236f6608522450d00da88033 https://github.com/pharo-project/pharo-core/commit/21e23792122a9d10236f6608… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-13 (Fri, 13 Feb 2015) Changed paths: M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/other-tests/testDifferentBlocksWithSameArgumentName.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/other-tests/testModulePrimitive.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/test - array compilation/testMultiElementArray.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/test - array compilation/testSimpleArray.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/test - block returning/testBlockReturning.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testBlockTemp.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testMethodArgument.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testMethodTemp.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testOneFloat.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testPragma.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testReturnBlockInMethod.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testSetUp.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testSteamContentsLimitedToSequenceableCollectionClass.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testToDoArgumentNotInlined.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testToDoInsideTempNotInlined.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testToDoOutsideTempNotInlined.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testWhileModificationAfterNotInlined.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testWhileModificationBeforeNotInlined.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testWhileWithTempNotInlined.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script487.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40487.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot-Tests.package/SlotIntegrationTest.class/instance/tests/testRemoveInstVarNamed.st A Slot-Tests.package/SlotIntegrationTest.class/instance/tests/testSlotNamedIfFoundIfNone.st M Slot.package/LayoutAbstractScope.class/instance/accessing/atName_ifFound_ifNone_.st Log Message: ----------- 40487 14906 Fix #slotNamed:ifFound:ifNone: https://pharo.fogbugz.com/f/cases/14906 14920 Replace senders of String>>#subStrings: in OpalCompiler-Tests https://pharo.fogbugz.com/f/cases/14920 14918 Pharo 4.0: Class Definitions not in Changes https://pharo.fogbugz.com/f/cases/14918/ http://files.pharo.org/image/40/40487.zip

Feb. 13, 2015

Re: [Pharo-dev] Extending NeoJSON

by S Krish

You are right. Stick to pure json spec is best as NeoJSON / Gson does. Anything else should be application's headache, exactly as Gson advices, as much is yours. I was just not shaking of the XMLRPC / SOA approach out of my head. It is getting cleared now. !.. let me work through my use case and come back if I need to at all on this. On Fri, Feb 13, 2015 at 7:04 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I had a more detailed look at json-io and read the code a bit. > > > First, this does not seem to be too popular in the Java world, there is no > formal spec, I don't see or hear about much uptake. So from that > perspective, why follow it ? > > Second, although at a first look their extensions seem reasonable, most > are quite Java specific, some inefficient. > > The contents of @class is pure Java, it can even include their ugly > primitive array syntax (like '[B') if I understood it well. How can that be > universally mapped to another, different language ? > > Their handling of primitive/non-primitive types (the endless int/Integer, > ... mess) makes the code quite complicated and some of that will probably > come through. We don't have those artificial differences. > > Their custom handling of some special classes (Date, Timestamp, Timezone, > Class, ..) is understandable but again Java specific and not formally > written in a spec. > > There seems to be @items and @keys fields that look suspicious. > > Any non-Java language will have trouble being 100% compatible with that > design. It is probably not impossible to do, but why would you want to do > that ? You will always be a second rank citizen. > > The handling of references using @id and @ref requires that the writer > makes two passes over the object graph (because it has to know up front > which objects will be used as reference targets). That is inefficient. > > Like I said, STON does all of the above, but a bit better, IMHO, but I am > biased of course. FUEL, although different by being binary, handles the > same and more edge cases. When you want to magically serialise *any* > object, you always hit (language) implementation details, which are not > good for cross language portability. > > > IMO, json-io was *not* written with the goal of being cross-platform > (meaning cross-language). > > There is a reason why JSON is what it is, limitations and all. It is quite > restricted, but it gives you portability. > > > All that being said, you could perfectly use Neo-JSON as a building block > to work with the json-io format, by going through a Maps/Lists > (Dictionary/Array) intermediate representation. It is a bit less efficient, > but I will work. > > Point>>#asJsonIo > ^ { #'@class'->'java.awt.Point'. #x->x. #y->y } asDictionary > > Point class>>#fromJsonIo: map > ^ self x: (map at: #x) y: (map at: #y) > > You will have to maintain a Point to 'java.awt.Point' mapping. And you > will have to walk the object graph to handles references. > > But it will take time to get feature equality and a functioning > implementation. > > > Sven > > > On 12 Feb 2015, at 11:01, S Krish <krishnamachari.sudhakar(a)gmail.com> > wrote: > > > > > > > > https://github.com/jdereg/json-io > > > > I like the additional features of json-io : @ref / @id pair > > > > If we can have an JSONExtension which plays well with json-io, we have a > simple way to interact with Java/Scala/Groovy JVM world for default. > > > > Present these as literals: String, Numbers, Date, Time, Literal Arrays , > booleans > > > > Rest all are type based marshalling/ unmarshalling > > > > "@type": "fully.qualified.name.toClass" for Pharo we can ignore the > package name.. which can be the Category specifier for serialization > purposes. > > > > > > > > > > On Thu, Feb 12, 2015 at 3:05 PM, S Krish < > krishnamachari.sudhakar(a)gmail.com> wrote: > > > > Even for GSON: > > > > > http://www.javacodegeeks.com/2012/04/json-with-gson-and-abstract-classes.ht… > > > > { > > > > "type": "Circle", > > "properties": { > > > > though I prefer json-io: @type to make it unambigous for any case with > instance variable named type and does not add another node to the tree.. > > > > > > > > On Thu, Feb 12, 2015 at 2:58 PM, S Krish < > krishnamachari.sudhakar(a)gmail.com> wrote: > > > > I get your point .. like GSON we should not type the json string output, > if we want it to adhere abs to spec. > > > > The saving grace for gson in Java is if you just give the root level > object type, rest of it is automatic typing. We lack that capability in > Pharo. Though there also for types specified as an interface can then > require code assistance in deserializing. > > > > So either we follow a meta data route, code helper methods, that is > needed for deserializing a JSON as spec or let it have an optional @type > tag.. to make the whole thing automatic > > > > That way we can be both gson / or any other lib compatible for reading > given format ignoring the extra tag, but helps if given to hydrate the > object. > > > > > > > > > > On Thu, Feb 12, 2015 at 1:13 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Hi, > > > > I will read a bit about json-io and come back to you. > > > > In any case, JSON is a standard that explicitly excludes typing info, > and yes I know it has been added in several places. NeoJSON's mission is to > stay true to the pure spec and to be efficient. Of course, it could be > extended or subclassed if its original goals remain in place. > > > > BTW, STON is what I think JSON with typing info should be ;-) > > > > Sven > > > > > On 12 Feb 2015, at 06:33, S Krish <krishnamachari.sudhakar(a)gmail.com> > wrote: > > > > > > > > > > > > Can I extend NeoJSON to be more like json-io. > > > > > > * Object serialization > > > * format synchronization > > > > > > To help make it bidirectional for Pharo to external world > serialization / deserialization > > > > > > > > > Seems the closest to what is appropriate for Pharo - Scala/ Groovy / > Java > > > > > > > > > Gson : no type information.. > > > Jackson: painful annotation or workarounds > > > > > > > > > > > > > > > > > > >

Feb. 13, 2015

Re: [Pharo-dev] Extending NeoJSON

by Sven Van Caekenberghe

Hi, I had a more detailed look at json-io and read the code a bit. First, this does not seem to be too popular in the Java world, there is no formal spec, I don't see or hear about much uptake. So from that perspective, why follow it ? Second, although at a first look their extensions seem reasonable, most are quite Java specific, some inefficient. The contents of @class is pure Java, it can even include their ugly primitive array syntax (like '[B') if I understood it well. How can that be universally mapped to another, different language ? Their handling of primitive/non-primitive types (the endless int/Integer, ... mess) makes the code quite complicated and some of that will probably come through. We don't have those artificial differences. Their custom handling of some special classes (Date, Timestamp, Timezone, Class, ..) is understandable but again Java specific and not formally written in a spec. There seems to be @items and @keys fields that look suspicious. Any non-Java language will have trouble being 100% compatible with that design. It is probably not impossible to do, but why would you want to do that ? You will always be a second rank citizen. The handling of references using @id and @ref requires that the writer makes two passes over the object graph (because it has to know up front which objects will be used as reference targets). That is inefficient. Like I said, STON does all of the above, but a bit better, IMHO, but I am biased of course. FUEL, although different by being binary, handles the same and more edge cases. When you want to magically serialise *any* object, you always hit (language) implementation details, which are not good for cross language portability. IMO, json-io was *not* written with the goal of being cross-platform (meaning cross-language). There is a reason why JSON is what it is, limitations and all. It is quite restricted, but it gives you portability. All that being said, you could perfectly use Neo-JSON as a building block to work with the json-io format, by going through a Maps/Lists (Dictionary/Array) intermediate representation. It is a bit less efficient, but I will work. Point>>#asJsonIo ^ { #'@class'->'java.awt.Point'. #x->x. #y->y } asDictionary Point class>>#fromJsonIo: map ^ self x: (map at: #x) y: (map at: #y) You will have to maintain a Point to 'java.awt.Point' mapping. And you will have to walk the object graph to handles references. But it will take time to get feature equality and a functioning implementation. Sven > On 12 Feb 2015, at 11:01, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > > > https://github.com/jdereg/json-io > > I like the additional features of json-io : @ref / @id pair > > If we can have an JSONExtension which plays well with json-io, we have a simple way to interact with Java/Scala/Groovy JVM world for default. > > Present these as literals: String, Numbers, Date, Time, Literal Arrays , booleans > > Rest all are type based marshalling/ unmarshalling > > "@type": "fully.qualified.name.toClass" for Pharo we can ignore the package name.. which can be the Category specifier for serialization purposes. > > > > > On Thu, Feb 12, 2015 at 3:05 PM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > Even for GSON: > > http://www.javacodegeeks.com/2012/04/json-with-gson-and-abstract-classes.ht… > > { > > "type": "Circle", > "properties": { > > though I prefer json-io: @type to make it unambigous for any case with instance variable named type and does not add another node to the tree.. > > > > On Thu, Feb 12, 2015 at 2:58 PM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > I get your point .. like GSON we should not type the json string output, if we want it to adhere abs to spec. > > The saving grace for gson in Java is if you just give the root level object type, rest of it is automatic typing. We lack that capability in Pharo. Though there also for types specified as an interface can then require code assistance in deserializing. > > So either we follow a meta data route, code helper methods, that is needed for deserializing a JSON as spec or let it have an optional @type tag.. to make the whole thing automatic > > That way we can be both gson / or any other lib compatible for reading given format ignoring the extra tag, but helps if given to hydrate the object. > > > > > On Thu, Feb 12, 2015 at 1:13 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I will read a bit about json-io and come back to you. > > In any case, JSON is a standard that explicitly excludes typing info, and yes I know it has been added in several places. NeoJSON's mission is to stay true to the pure spec and to be efficient. Of course, it could be extended or subclassed if its original goals remain in place. > > BTW, STON is what I think JSON with typing info should be ;-) > > Sven > > > On 12 Feb 2015, at 06:33, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > > > > > > > Can I extend NeoJSON to be more like json-io. > > > > * Object serialization > > * format synchronization > > > > To help make it bidirectional for Pharo to external world serialization / deserialization > > > > > > Seems the closest to what is appropriate for Pharo - Scala/ Groovy / Java > > > > > > Gson : no type information.. > > Jackson: painful annotation or workarounds > > > > > > > > >

Feb. 13, 2015

Re: [Pharo-dev] [Pharo CI] Jenkins down 10/11 Feb

by Christophe Demarey

Le 13 fÃ©vr. 2015 Ã 13:46, Tudor Girba a Ã©crit : > Thanks, indeed! > > I am trying to relaunch the slaves for Moose (https://ci.inria.fr/moose) but I am somehow unable to accomplish that. Could you take a look at this as well? Done! If you want to do start/stop slaves by yourself, you need to go to https://ci.inria.fr/project/moose/slaves#. To speed-up things, then go to jenkins / manage Jenkins / manage nodes and click on a slave and finally click on "Launch slave agent"

Feb. 13, 2015

Re: [Pharo-dev] [Pharo CI] Jenkins down 10/11 Feb

by Tudor Girba

Thanks, indeed! I am trying to relaunch the slaves for Moose (https://ci.inria.fr/moose) but I am somehow unable to accomplish that. Could you take a look at this as well? Cheers, Doru On Fri, Feb 13, 2015 at 10:10 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Thanks a lot! > > Marcus > > On 13 Feb 2015, at 10:01, Christophe Demarey <Christophe.Demarey(a)inria.fr> > wrote: > > > Le 13 fÃ©vr. 2015 Ã 08:31, Marcus Denker a Ã©crit : > > > On 13 Feb 2015, at 01:56, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Are there any news on this? :) > > > The update has been done. > > Now we need to > > -> check why https://ci.inria.fr/pharo/ is not up > -> restart all slaves everywhere > > > I just did that for pharo and pharo-contrib > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 13, 2015

Re: [Pharo-dev] Ubunti 14.04 32bit install error

by Damien Cassou

Markus Fritsche writes: > Hello Brad, > > Yes, there's already a fixed image in the queue, however, it's > stuck right now as far as I understand. the Continuous Integration Server was down. But everything is fixed now and you can enjoy the new launcher. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Feb. 13, 2015

Re: [Pharo-dev] [Pharo CI] Jenkins down 10/11 Feb

by Marcus Denker

Thanks a lot! Marcus > On 13 Feb 2015, at 10:01, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > > Le 13 fÃ©vr. 2015 Ã 08:31, Marcus Denker a Ã©crit : > >> >>> On 13 Feb 2015, at 01:56, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>> Are there any news on this? :) >>> >> >> The update has been done. >> >> Now we need to >> >> -> check why https://ci.inria.fr/pharo/ <https://ci.inria.fr/pharo/> is not up >> -> restart all slaves everywhere > > I just did that for pharo and pharo-contrib >

Feb. 13, 2015

Re: [Pharo-dev] [Pharo CI] Jenkins down 10/11 Feb

by Christophe Demarey

Le 13 fÃ©vr. 2015 Ã 08:31, Marcus Denker a Ã©crit : > >> On 13 Feb 2015, at 01:56, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Are there any news on this? :) >> > > The update has been done. > > Now we need to > > -> check why https://ci.inria.fr/pharo/ is not up > -> restart all slaves everywhere I just did that for pharo and pharo-contrib

Feb. 13, 2015

Re: [Pharo-dev] [Pharo CI] Jenkins down 10/11 Feb

by Marcus Denker

> On 13 Feb 2015, at 01:56, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Are there any news on this? :) > The update has been done. Now we need to -> check why https://ci.inria.fr/pharo/ <https://ci.inria.fr/pharo/> is not up -> restart all slaves everywhere >> On 10 Feb 2015, at 16:50, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> This is todayâ¦ >> >> >> >>> >>> There will a big update of the Inria CI infrastructure. >>> >>> On 10 Feb the system will go offline 5PM Paris time, it will >>> be online the 12th hopefully latest. >>> >>> Why? For now the system just supports Win and Linux. >>> This update will add the base for MacOS vitual servers. >>> (If you wonder how it works now: we have a non-virtual >>> Mac in our office that runs all mac buildsâ¦) >>> >>> Marcus >> >> > >

Feb. 13, 2015