November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo on Online Labs ARM cloud server ?

by stepharo

JB has some jenkins job but I do not know their status. JB? Stef On 13/11/14 23:34, Sven Van Caekenberghe wrote: > Hi, > > I just saw this: http://labs.online.net which offers real ARM cloud servers (15 minutes for free to try out) [they're French]. This is Ubuntu 14.10 on ARMv7. > > Naturally I wanted to try Pharo on such a machine. > > The base question is, where do I get the latest and best VM to try this ? > > Maybe a complete & easy to use source tree that can be compiled locally ? > > And would it make sense to add some ARM option to get.pharo.org ? > > Thx, > > Sven >

Nov. 14, 2014

Pharo Launcher for Windows

by Thierry Goubier

Hi all, does anybody knows if the Pharo Launcher is working in Windows? I tried on different Windows 7 machines, but it would work nor give any error message at all. (Note: Pharo3 windows distribution did work). Thanks, Thierry

Nov. 14, 2014

Re: [Pharo-dev] Pharo on Online Labs ARM cloud server ?

by ClÃ©ment Bera

There was a mail from Doug McPherson recently about that. *Pre-built Squeak stack and stack/spur VMs for ARMv6 (i.e. Raspberry Pi) and ARMv7 (i.e. BeagleBone Black, Parallella, numerous Chromebooks, etc) are now available at the same location as the other Cog and Spur VMs. * *( http://www.mirandabanda.org/files/Cog/VM/VM.r3126/ <http://www.mirandabanda.org/files/Cog/VM/VM.r3126/> ). * *Bug reports, questions, and comments welcome.* 2014-11-14 1:02 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Sven, > > On Thu, Nov 13, 2014 at 2:34 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Hi, >> >> I just saw this: http://labs.online.net which offers real ARM cloud >> servers (15 minutes for free to try out) [they're French]. This is Ubuntu >> 14.10 on ARMv7. >> >> Naturally I wanted to try Pharo on such a machine. >> >> The base question is, where do I get the latest and best VM to try this ? >> > > Doug McPherson is building Stack VMs for ARMv6 and ARMv7 for both Cog and > Spur and uploading them to my site. These VMs should run Pharo. See e.g. > http://www.mirandabanda.org/files/Cog/VM/VM.r3126/ > > Maybe a complete & easy to use source tree that can be compiled locally ? >> > > That's the case for http://www.squeakvm.org/svn/squeak/branches/Cog. > See http://www.squeakvm.org/svn/squeak/branches/Cog/build.linux32ARM > > And would it make sense to add some ARM option to get.pharo.org ? >> >> Thx, >> >> Sven >> > > > > -- > best, > Eliot >

Nov. 14, 2014

Re: [Pharo-dev] Pharo on Online Labs ARM cloud server ?

by Eliot Miranda

Hi Sven, On Thu, Nov 13, 2014 at 2:34 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I just saw this: http://labs.online.net which offers real ARM cloud > servers (15 minutes for free to try out) [they're French]. This is Ubuntu > 14.10 on ARMv7. > > Naturally I wanted to try Pharo on such a machine. > > The base question is, where do I get the latest and best VM to try this ? > Doug McPherson is building Stack VMs for ARMv6 and ARMv7 for both Cog and Spur and uploading them to my site. These VMs should run Pharo. See e.g. http://www.mirandabanda.org/files/Cog/VM/VM.r3126/ Maybe a complete & easy to use source tree that can be compiled locally ? > That's the case for http://www.squeakvm.org/svn/squeak/branches/Cog. See http://www.squeakvm.org/svn/squeak/branches/Cog/build.linux32ARM And would it make sense to add some ARM option to get.pharo.org ? > > Thx, > > Sven > -- best, Eliot

Nov. 14, 2014

Re: [Pharo-dev] [Vm-dev] Re: How to check whether the handle is always valid with NativeBoost ?

by Igor Stasenko

On 13 November 2014 18:37, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Vincent, > > one way, used in VisualWorks, is to ensure that only valid handles > exist. So very early at startup the system does some allInstances > invocations on the classes of handles and invalidates all the handles > found. This doesn't fix handles stored as raw integers anywhere, but > provided the system is designed to have specific objects for external > handles (and I hope it is) this shouldn't happen. > > Since snapshot is relatively rare and start-up relatively frequent (at > least in e.g. a web deployment context), one performance improvement is to > do the allInstances before snapshot, and then merely enumerate the > collection of handles, rather than use allInstances. > > Just to add: - (re)validating external resources could vary depending on library or how short/long-lived the resource is etc. As you described, one of the scenarios is to flush invalid handles at system startup. In NB i using session checking, to do it lazily, once there's an attempt to use external resource. But all that, of course, doesn't addresses the problem when external resource get invalidated, for one or another reason, during same session. Using proxy to control each and every access to external resource is, of course, an ultimate solution, but alas, quite expensive since imposes high overhead. I would call it a brute-force solution. To minimize overhead, my approach often is to place a check at key entry part of algorithm, so if check passed, then rest of algorithm can run safely without excessive checking. But that really depends on design of external library/framework, whether it possible or not. Usually, if you cleverly organize the access to services, it is possible to do it without using brute-force proxyfying. On Thu, Nov 13, 2014 at 9:05 AM, Blondeau Vincent < > vincent.blondeau(a)worldline.com> wrote: > >> Hi ! >> >> >> >> I am doing a binding to the R library with NativeBoost. >> >> So I create some external objects and apply some functions on them. >> >> >> >> If the handle to the object is not valid, either the function crashes or >> gives a bad result. >> >> >> >> How can I ensure to have a valid pointer at anytime ? >> >> >> >> I see two solutions: >> >> - Either check at any NativeBoost call that the handle is valid >> (by checking the session id) >> >> - Or do a proxy that checks the session and recreate the >> external object. >> >> >> >> What do you think ? >> >> >> >> Thanks in advance, >> >> >> >> Cheers, >> >> Vincent BLONDEAU >> >> >> >> ------------------------------ >> >> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage >> exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne >> pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra >> Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs >> efforts soient faits pour maintenir cette transmission exempte de tout >> virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa >> responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As >> its integrity cannot be secured on the Internet, the Worldline liability >> cannot be triggered for the message content. Although the sender endeavours >> to maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. >> > > > > -- > best, > Eliot > > -- Best regards, Igor Stasenko.

Nov. 13, 2014

Pharo on Online Labs ARM cloud server ?

by Sven Van Caekenberghe

Hi, I just saw this: http://labs.online.net which offers real ARM cloud servers (15 minutes for free to try out) [they're French]. This is Ubuntu 14.10 on ARMv7. Naturally I wanted to try Pharo on such a machine. The base question is, where do I get the latest and best VM to try this ? Maybe a complete & easy to use source tree that can be compiled locally ? And would it make sense to add some ARM option to get.pharo.org ? Thx, Sven

Nov. 13, 2014

Spur Identity Hash [was: The Trunk: System-cmm.689.mcz]

by Eliot Miranda

Hi Chris, interesting! On Wed, Nov 12, 2014 at 1:40 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > I finally tracked down why the keys of the #knownEnvironments > Dictionary were changing when trying to build an image in Spur. > > It's because, in my core-extensions package, I override > UndefinedObject>>#hash to have hard-coded value independent of its > #identityHash, to be safer with distributed systems which may be using > nil in a hash calculation -- in case they would be different due to > accessing with a Spur image, for example. > > Such a hash calculation is made for the keys of the #knownEnvironments > Dictionary when the country's are nil. By the different hash value in > Spur, the image would lock when trying to load my core-extensions > package, because it tried to access knownEnvironments as part of the > load-operation itself. > > The least-lazy way to "fix" it was to ensure something is populated in > the LocaleID's 'country's. Whew! > > Anyway, something to be aware of -- anywhere we have true, false or > nil used in a hash calculation, now has a different hash in Spur vs. > Cog. Maybe we should think about separating those objects' logical > "value" hash from their identityHash in trunk..? That could be useful > when we move to 64-bit someday.. > Remember that Spur has a common header format for both 32-bit and 64-bit versions, so in both there is a 22-bit identityHash and hence the identityHashes of all objects in a 64-bit Spur image bootstrapped from a 32-bit Spur image will be _unchanged_. Convenient. So no need to worry. And it should be the case that a freshly bootstrapped 64-bit Spur image does not need to be rehashed to function properly. But while we're on the subject, one thing we could do is arrange that Symbols have an identityHash based on their value. So when interning a string we'd compute its string hash and derive and assign the identityHash of the Symbol from the string hash. That would mean that when unpickling classes in e.g. Fuel we would not have to rehash method dictionaries, which would be very nice indeed. On Wed, Nov 12, 2014 at 3:26 PM, <commits(a)source.squeak.org> wrote: > > Chris Muller uploaded a new version of System to project The Trunk: > > http://source.squeak.org/trunk/System-cmm.689.mcz > > > > ==================== Summary ==================== > > > > Name: System-cmm.689 > > Author: cmm > > Time: 12 November 2014, 3:19:56.156 pm > > UUID: a1ffba24-42ff-4391-9387-4e8ee20e6b2a > > Ancestors: System-ul.688 > > > > Populate all LocaleID's 'country's. > > > > =============== Diff against System-ul.688 =============== > > > > Item was added: > > + ----- Method: LocaleID class>>countryFor: (in category 'accessing') > ----- > > + countryFor: iso6391Code > > + "http://www.loc.gov/standards/iso639-2/php/code_list.php" > > + ^ iso6391Code > > + caseOf: > > + { ['af'] -> ['Afrikaans']. > > + ['ca'] -> ['Catalan']. > > + ['cs'] -> [ 'Czech']. > > + ['da'] -> [ 'Danish']. > > + ['de'] -> [ 'German']. > > + ['el'] -> [ 'Greek Modern']. > > + ['en'] -> [ 'English']. > > + ['es'] -> [ 'Spanish']. > > + ['eu'] -> [ 'Basque']. > > + ['fi'] -> [ 'Finnish']. > > + ['fo'] -> [ 'Faroese']. > > + ['fr'] -> [ 'French']. > > + ['ga'] -> [ 'Irish']. > > + ['gd'] -> [ 'Gaelic']. > > + ['hr'] -> [ 'Croatian']. > > + ['hu'] -> [ 'Hungarian']. > > + ['is'] -> [ 'Icelandic']. > > + ['it'] -> [ 'Italian']. > > + ['ja'] -> [ 'Japanese']. > > + ['ja-etoys'] -> [ 'Japanese']. > > + ['ko'] -> [ 'Korean']. > > + ['nl'] -> [ 'Dutch']. > > + ['no'] -> [ 'Norwegian']. > > + ['pt'] -> [ 'Portuguese']. > > + ['rm'] -> [ 'Romansh']. > > + ['ro'] -> [ 'Romainian']. > > + ['sk'] -> [ 'Slovak']. > > + ['sl'] -> [ 'Slovenian']. > > + ['sq'] -> [ 'Albanian']. > > + ['sv'] -> [ 'Swedish']. > > + ['sw'] -> [ 'Swahili']. > > + ['zh'] -> [ 'Chinese'] } > > + otherwise: > > + [ 'other' ]! > > > > Item was changed: > > ----- Method: LocaleID>>isoLanguage:isoCountry: (in category > 'initialize') ----- > > + isoLanguage: langString isoCountry: countryStringOrNil > > - isoLanguage: langString isoCountry: countryStringOrNil > > isoLanguage := langString. > > + isoCountry := countryStringOrNil ifNil: (self class countryFor: > langString)! > > - isoCountry := countryStringOrNil! > > > > Item was changed: > > (PackageInfo named: 'System') postscript: '"Preferences already > removed by hand, but whose state still lingers:" > > + LocaleID allInstances do: > > + [ : each | each > > + isoLanguage: each isoLanguage > > + isoCountry: (each isoCountry ifNil: [ each isoCountry ]) > ]. > > + LanguageEnvironment knownEnvironments rehash'! > > - Preferences removePreference: #upgradeIsMerge. > > - Preferences removePreference: #colorWhenPrettyPrinting. > > - Preferences removePreference: #promptForUpdateServer. > > - Preferences removePreference: #updateSavesFile. > > - Preferences removePreference: #updateFromServerAtStartup.'! > > > > > > -- best, Eliot

Nov. 13, 2014

Re: [Pharo-dev] What happened to CompiledMethod>>#numLiterals in Spur?

by Eliot Miranda

Hi Chris, On Thu, Nov 13, 2014 at 12:24 PM, Chris Muller <ma.chris.m(a)gmail.com> wrote: > Hi Eliot and all, while moving some serialized objects from a Cog > image into a Spur image, I am encountered an issue materializaing a > CompiledMethod instance in the target Spur image due to the new > implementation of #numLiterals. In Cog it's: > > numLiterals > "Answer the number of literals used by the receiver." > | header | > ^(header := self header) < 0 > ifTrue: [header bitAnd: 65535] > ifFalse: [(header bitShift: -9) bitAnd: 16rFF] > > but in Spur, only the negative header condition is present: > > numLiterals > "Answer the number of literals used by the receiver." > ^self header bitAnd: 65535 > Right. The header was positive in the source Cog image, in fact, there are NO > instances of CM's with negative headers in either my Cog or Spur > images. So after constructing the CompiledMethod for materialization > within the Spur image with the same #header it had in Cog, it reports > the wrong #numLiterals and can't finish the materialization because of > that. > Right. I'm able to force a correct materialization by changing the place > where I access "numLiterals" to the original True condition of Cog -- > "(header bitShift: -9) bitAnd: 16rFF". > Good. That is the "right thing to do" (tm). Or rather it is the right thing to do when trying to import methods from Cog to Spur. But that's just "making it work" and not understanding the > implications of what I'm doing. I know Spur can allow more literals > per CM, but assuming I'm willing to stay with a max of just 255 > literals for now, is my override above the best way to handle this > need to be able to transfer objects back-and-forth within a > heterogeneous environment of Cog and Spur images? > Yes, as long as it is on;y used for porting. You obviously /don'/ need it when materializing in Spur methods that have been dematerialized in Spur (BTW, I like the "official" terms, "pickled" and "unpickled"). Thanks for any advice and insight.. > So the new format was introduced to lift the limit on the number of literals. I first implemented it for Newspeak a couple of years ago for Cadence. At this point it used the sign bit to allow both the old and new header formats to coexist: numLiterals "Answer the number of literals used by the receiver." | header | ^(header := self header) < 0 ifTrue: [header bitAnd: 65535] ifFalse: [(header bitShift: -9) bitAnd: 16rFF] The problems with this are - that sign bit allows choosing between bytecode sets, and so it couples bytecode set choice with literal limit, and - there is a cost, at least in code density, even if not necessarily much in performance, in the VM using the "mixed" format. I realised in late summer with Spur that I had a chance of eliminating the coupling and performance issues by insisting on the one format in Spur. So I decided to eliminate the old format and just go with the simple format (this taken from CompiledMethod's class comment in its Spur version): The header is a 31-bit signed integer (a SmallInteger) in the following format: (index 0) 16 bits: number of literals (#numLiterals) (index 16) 1 bit: has primitive (index 17) 1 bit: whether a large frame size is needed (#frameSize => either SmallFrame or LargeFrame) (index 18) 6 bits: number of temporary variables (#numTemps) (index 24) 4 bits: number of arguments to the method (#numArgs) (index 28) 2 bits: reserved for an access modifier (00-unused, 01-private, 10-protected, 11-public), although accessors for bit 29 exist (see #flag). (index 30/63) sign bit: 1 selects the Secondary instruction set (e.g. NewsqueakV4, 0 selects the primary instruction set, e.g. SqueakV3PlusClosures) (#signFlag) This a) makes the VM slimmer and b) makes it much less complicated to use the two bytecode sets. The ability to use two bytecode sets provides a smoother transition to Sista when it arrives next year. -- best, Eliot

Nov. 13, 2014

Re: [Pharo-dev] [OT] .NET OpenSource

by Alain Rastoul

Le 13/11/2014 20:28, phil(a)highoctane.be a Ã©crit : > 0mqâ looks like a damn good answer to that if you ask me. yes it looks like, but albeit I like it's conceptual design, and like it because it is small and simple, I'm not sure about that now that I tryed it. As I said in a previous post, answering to stef about 0mq, I'm very disappointed with this library. I suspect there is some problem (or side effect) of the signal handling in pharo vm with 0mq (the reason for it not working on linux, and probably the reason for the bad performance I noticed in my first trials on windows), posted a question in the 0mq mailing list about that and what I found debugging the 0mq library, and got no answer. I think 0mq developpers are somewhat interested with mainstream languages but not really ready to help everybody (and probably they can't too, I understand that). About interoperability, stomp, openwire and amqp sounds also very interesting and much more open to the enterprise world and cloud (rabbitmq, activemq, apollo, qpid, msmq just to name the big ones). I'm working on that.

Nov. 13, 2014

Re: [Pharo-dev] [Article] Lambda Calculus in Pharo

by Alain Rastoul

wow, excellent ! after a day job, a little bit hard to follow you on that one right now, I'll reread that head rested I like that kind of articles :) Le 13/11/2014 16:54, Sven Van Caekenberghe a Ã©crit : > Hi, > > I was hacking a bit and one thing let to another and I ended up writing and publishing another short article: > > Lambda Calculus in Pharo > > Yes, the Y Combinator is useful in normal programs > > https://medium.com/@svenvc/lambda-calculus-in-pharo-a4a571869594 > > Enjoy, > > Sven > > >

Nov. 13, 2014