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

Ubunti 14.04 32bit install error

by bsselfridge＠gmail.com

When I try to install Pharo 3.0 on Ubuntu 14.04 LTS, I get the following error when running the "sudo apt-get install pharo-launcher" command: The following packages have unmet dependencies: pharo-launcher : Depends: pharo-vm-desktop:i386 but it is not installable E: Unable to correct problems, you have held broken packages. ----- Brad Selfridge -- View this message in context: http://forum.world.st/Ubunti-14-04-32bit-install-error-tp4805391.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 12, 2015

Re: [Pharo-dev] [Vm-dev] re: Reducing the activity of the image

by Eliot Miranda

On Thu, Feb 12, 2015 at 10:45 AM, John McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > > Craig so how does using pthread_cond_timedwait affect socket processing? > The promise of nanosleep was to wake up if an interrupt arrived say on a > socket (Mind I never actually confirmed this the case, complete hearsay...) > +1. What he said. The problem with pthread_cond_timed_wait, or any other merely delaying call is that, unless all file descriptors have been set up to send signals on read/writability and unless the blocking call is interruptible, the call may block for as long as it is asked, not until that or the read/writeability of the file descriptor. IMO a better solution here is to a) use epoll or its equivalent kqueue; these are like select but the state of which selectors to examine is kept in kernel space, so the set-up overhead is vastly reduced, and b) wait for no longer than the next scheduled delay if one is in progres. Of course, the VM can do both of these things, and then there's no need for a background process at all. Instead, when the V< scheduler finds there's nothing to run it calls epoll or kqueue with either an infinite timeout (if no delay is in progress) or the time until the next delay expiration. Now, if only there was more time ;-) It strikes me that the VM can have a flag that makes it behave like this so that e.g. some time in the Spur release cycle we can set the flag, nuke the background process and get on with our lives. > On Thu, Feb 12, 2015 at 2:40 AM, Craig Latta <craig(a)netjam.org> wrote: > >> >> >> Hoi Norbert-- >> >> In 2003, while implementing remote messaging for what became the >> Naiad distributed module system[1], I noticed excessive CPU usage during >> idle by Squeak on MacOSX (and extremely poor remote messaging >> performance). I prepared alternate versions of >> ioRelinquishProcessorForMicroseconds, comparing: >> >> - select() (AKA aioSleepForUsecs in Ian's aio API, my starting point) >> - pthread_cond_timedwait() >> - nanosleep() >> >> pthread_cond_timedwait was the clear winner at the time. I wrote my >> own relinquish primitive as part of the Flow external streaming >> plugin[2], and I've been using it ever since. Still seems fine. I've >> mentioned this before. >> >> >> thanks, >> >> -C >> >> [1] http://netjam.org/naiad >> [1] http://netjam.org/flow >> >> -- >> Craig Latta >> netjam.org >> +31 6 2757 7177 (SMS ok) >> + 1 415 287 3547 (no SMS) >> >> > > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > https://www.linkedin.com/in/smalltalk > =========================================================================== > > -- best, Eliot

Feb. 12, 2015

Re: [Pharo-dev] [Vm-dev] re: Reducing the activity of the image

by John McIntosh

Craig so how does using pthread_cond_timedwait affect socket processing? The promise of nanosleep was to wake up if an interrupt arrived say on a socket (Mind I never actually confirmed this the case, complete hearsay...) On Thu, Feb 12, 2015 at 2:40 AM, Craig Latta <craig(a)netjam.org> wrote: > > > Hoi Norbert-- > > In 2003, while implementing remote messaging for what became the > Naiad distributed module system[1], I noticed excessive CPU usage during > idle by Squeak on MacOSX (and extremely poor remote messaging > performance). I prepared alternate versions of > ioRelinquishProcessorForMicroseconds, comparing: > > - select() (AKA aioSleepForUsecs in Ian's aio API, my starting point) > - pthread_cond_timedwait() > - nanosleep() > > pthread_cond_timedwait was the clear winner at the time. I wrote my > own relinquish primitive as part of the Flow external streaming > plugin[2], and I've been using it ever since. Still seems fine. I've > mentioned this before. > > > thanks, > > -C > > [1] http://netjam.org/naiad > [1] http://netjam.org/flow > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> https://www.linkedin.com/in/smalltalk ===========================================================================

Feb. 12, 2015

[Job][Research] Inria Competitive selection 2015 : young graduate scientist ("CR2")

by Marcus Denker

Competitive selection 2015 : young graduate scientist ("CR2") Inria is launching a round of competitions to recruit seventeen young graduate scientists. Theses positions will be allocated as follows: two positions at Grenoble, Lille, Nancy, Rennes, Rocquencourt, Saclay and Sophia-Antipolis research centres and three positions at Bordeaux research centre. Registration conditions ================== Registration for the young graduate scientist competition begins on 26 January 2015. The following may apply: â¢ Holders of a doctorate or equivalent degree; â¢ Applicants able to prove publications and scientific work deemed equivalent. There are no age limits or nationality requirements for the recruitment of young graduated scientists. DEADLINE: ========= â¢ 20 February 2015: Deadline for downloading application files â¢ 23 February 2015: Deadline for submitting application files More information: http://www.inria.fr/en/institute/recruitment/offers/young-graduate-scientis…

Feb. 12, 2015

Re: [Pharo-dev] Matrix API question for a native english

by Craig Latta

Hoi Stef-- > So should we use rowCount for method argument? > because we got rows: rows meaning rows: rowCount and I rewrote them as > rows: rowNumber but it could be better to have > rows: rowCount. "numberOfRows" is unambiguous, in both a selector and a variable name. Therefore (in my opinion as a native English speaker :), it is better than the alternatives mentioned. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Feb. 12, 2015

Re: [Pharo-dev] Extending NeoJSON

by S Krish

https://github.com/jdereg/json-io <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. 12, 2015

Re: [Pharo-dev] Extending NeoJSON

by S Krish

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. 12, 2015

Re: [Pharo-dev] Extending NeoJSON

by S Krish

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. 12, 2015

Re: [Pharo-dev] Running some code at fogbugz CI

by stepharo

One step at the time and pushing regularly. Stef >> On 10 Feb 2015, at 23:20, Pablo Herrero <pablodherrero(a)gmail.com> wrote: >> >> Ok, thanks Nicolas for letting me now, the test suite should be green now. >> BTW, this is the list of packages I'm testing for this: AST-Core, >> AST-Interpreter, Collections-Strings, NodeNavigation, OpalCompiler, >> OpalDecompiler, Refactoring, SmartSuggestions and Shout. >> (There could be more that are also important anyway). >> > I really need to review your changeâ¦ sometimes I wonderâ¦ so much todo > and I feel I could work double and it would still not be enough. > > Marcus >

Feb. 12, 2015

Re: [Pharo-dev] Extending NeoJSON

by Sven Van Caekenberghe

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. 12, 2015