- Pharo-dev - lists.pharo.org

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

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

by phil＠highoctane.be

0mqâ looks like a damn good answer to that if you ask me. Phil

Nov. 13, 2014

[pharo-project/pharo-core]

by GitHub

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

Nov. 13, 2014

[pharo-project/pharo-core] 81bcfc: 40369

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 81bcfcba1bb6d5d9a9334217427b86d44f940ec0 https://github.com/pharo-project/pharo-core/commit/81bcfcba1bb6d5d9a9334217… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-11-13 (Thu, 13 Nov 2014) Changed paths: M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version201_.st M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version201_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version301_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version123_.st M GT-Inspector.package/GTInspector.class/instance/building/compose.st A GT-InspectorExtensions-Core.package/extension/MetacelloVersion/instance/gtInspectorProjectsIn_.st A GT-InspectorExtensions-Core.package/extension/RPackage/instance/gtInspectorDefinedClassesIn_.st A GT-InspectorExtensions-Core.package/extension/RPackage/instance/gtInspectorTagsIn_.st A GT-InspectorExtensions-Core.package/extension/RPackageTag/instance/gtInspectorDefinedClassesIn_.st M GT-Playground.package/GTPlayPage.class/instance/accessing/publishUrl.st M GT-Playground.package/GTUrlProvider.class/class/as yet unclassified/settingsOn_.st M Glamour-Core.package/GLMUpdateAction.class/instance/public/registerInPresentation.st R Glamour-Examples.package/GLMBasicExamples.class/instance/others/roassalPainting.st M Glamour-Morphic-Brick.package/GLMBrick.class/instance/adding/addBrickBack_.st A Glamour-Morphic-Brick.package/GLMBrick.class/instance/adding/addBrick_before_.st A Glamour-Morphic-Brick.package/GLMBrick.class/instance/initialization/initializeBrick_.st M Glamour-Morphic-Brick.package/GLMBrickHorizontalLinearLayout.class/instance/accessing/layout_in_.st M Glamour-Morphic-Brick.package/GLMBrickHorizontalProportionalLinearLayout.class/instance/accessing/layout_in_.st M Glamour-Morphic-Brick.package/GLMBrickVerticalLinearLayout.class/instance/as yet unclassified/layout_in_.st M Glamour-Morphic-Brick.package/GLMBrickVerticalProportionalLinearLayout.class/instance/accessing/layout_in_.st A Glamour-Morphic-Brick.package/GLMScrollPaneBrick.class/instance/adding/addBrick_before_.st R Glamour-Morphic-Pager.package/GLMButton.class/class/as yet unclassified/shrinkButtons_by_.st M Rubric.package/RubAbstractTextArea.class/class/settings/rubricSettingsOn_.st M Rubric.package/RubAbstractTextArea.class/instance/event handling/keyStroke_.st M Rubric.package/RubCursor.class/class/settings/rubricSettingsOn_.st M Rubric.package/RubPlainTextMode.class/class/menu/fontMenuOn_.st A Rubric.package/RubSHTextStylerST80.class/README.md A Rubric.package/RubSHTextStylerST80.class/definition.st A Rubric.package/RubSHTextStylerST80.class/instance/as yet unclassified/addLinkAttributesFor_in_to_.st M Rubric.package/RubSegmentMorph.class/definition.st M Rubric.package/RubSegmentMorph.class/instance/initialization/vertices_color_borderWidth_borderColor_.st M Rubric.package/RubSegmentMorph.class/instance/private/filledForm.st M Rubric.package/RubShoutStylerDecorator.class/instance/accessing/defaultStyler.st M Rubric.package/RubSmalltalkEditor.class/instance/menu messages/sendersOf_.st A Rubric.package/RubTextClassLink.class/README.md A Rubric.package/RubTextClassLink.class/class/as yet unclassified/className_.st A Rubric.package/RubTextClassLink.class/class/as yet unclassified/class_.st A Rubric.package/RubTextClassLink.class/definition.st A Rubric.package/RubTextClassLink.class/instance/accessing/className_.st A Rubric.package/RubTextClassLink.class/instance/evaluating/actOnClick_for_in_editor_.st A Rubric.package/RubTextClassLink.class/instance/system primitives/className.st A Rubric.package/RubTextLink.class/README.md A Rubric.package/RubTextLink.class/definition.st A Rubric.package/RubTextLink.class/instance/testing/mayActOnEvent_.st A Rubric.package/RubTextMethodLink.class/README.md A Rubric.package/RubTextMethodLink.class/class/as yet unclassified/selector_.st A Rubric.package/RubTextMethodLink.class/class/as yet unclassified/selector_senders_.st A Rubric.package/RubTextMethodLink.class/definition.st A Rubric.package/RubTextMethodLink.class/instance/accessing/selector.st A Rubric.package/RubTextMethodLink.class/instance/accessing/selector_.st A Rubric.package/RubTextMethodLink.class/instance/accessing/senders_.st A Rubric.package/RubTextMethodLink.class/instance/event handling/actOnClick_for_in_editor_.st A Rubric.package/RubTextMethodLink.class/instance/initialization/initialize.st A Rubric.package/RubTextVariableLink.class/README.md A Rubric.package/RubTextVariableLink.class/class/as yet unclassified/variableName_.st A Rubric.package/RubTextVariableLink.class/definition.st A Rubric.package/RubTextVariableLink.class/instance/accessing/variableName.st A Rubric.package/RubTextVariableLink.class/instance/accessing/variableName_.st A Rubric.package/RubTextVariableLink.class/instance/evaluating/actOnClick_for_in_editor_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script369.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40369.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40369 14467 GTools version 2.0.1 https://pharo.fogbugz.com/f/cases/14467 http://files.pharo.org/image/40/40369.zip

Nov. 13, 2014

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

by Alain Rastoul

A bridge is already possible with dotNet without the sources on windows using COM: one can load the clr as a COM object and call COM methods (googling quite a bit should give examples in c++ IIRC, and it works). The pain could be marshalling arguments/returns and may be also with the threading model of pharo (may be calling from another thread here?). I think it is the same with the jvm (examples of loading the jvm as a com object are given in the openoffice or staroffice sdk I think, but don't remember exactly - we did it with a collegue quite some time ago). Smalltalk main feature is simplicity and expressiveness and it's great, but smalltalk world suffers from beeing too apart from others and too closed. This could be a great opening door, interoperability and openness is needed (IMHO). Le 13/11/2014 15:52, phil(a)highoctane.be a Ã©crit : > Time for a bridge... But frankly .NET is a monster in termes of features > (WPF comes to mind). > > I've seen quite some projects die under the technical weight and > delivering close to nil in terms of added value. > > Phil

Nov. 13, 2014

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

by Alain Rastoul

Microsoft have to face big opensource codebase adoption in cloud Open source is no more a cancer or a virus now that they needs open source developers help them not to die ... :) Le 13/11/2014 15:27, Torsten Bergmann a Ã©crit : > For those of you who might be interested: > > .NET is open source with MIT license > - .NET Framework Libraries > - .NET Core Framework Libraries > - and the RyuJit VM > > http://tirania.org/blog/archive/2014/Nov-12.html > >

Nov. 13, 2014

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

by Eliot Miranda

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. 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

Nov. 13, 2014