- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Dec. 16, 2015

[pharo-project/pharo-core] 1c8126: 50502

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 1c8126fb073c0b8322f9a6238e45bfb07936e713 https://github.com/pharo-project/pharo-core/commit/1c8126fb073c0b8322f9a623… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-16 (Wed, 16 Dec 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50501.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50502.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50501.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50502.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Traits.package/TBehavior.class/instance/accessing instances and variables/allInstances.st M Traits.package/TBehavior.class/instance/accessing/typeOfClass.st M Traits.package/TBehavior.class/instance/enumerating/allInstancesDo_.st M Traits.package/TBehavior.class/instance/private/indexIfCompact.st M Traits.package/TBehavior.class/instance/testing class hierarchy/kindOfSubclass.st M Traits.package/TBehavior.class/instance/testing/instSpec.st M Traits.package/TBehavior.class/instance/testing/isBits.st M Traits.package/TBehavior.class/instance/testing/isBytes.st M Traits.package/TBehavior.class/instance/testing/isVariable.st Log Message: ----------- 50502 17250 copy methods from Behavior to TBehavior (spur migration) https://pharo.fogbugz.com/f/cases/17250 http://files.pharo.org/image/50/50502.zip

Dec. 16, 2015

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Re: [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: Unicode Support))

by Ben Coman

On Wed, Dec 16, 2015 at 6:22 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > On 12/16/15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi Todd, >> >> On Tue, Dec 15, 2015 at 3:46 PM, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >>> Hi Eliot, >>> >>> On Dec 15, 2015, at 13:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> Just so you know, I will dig my heels in as deeply as I am able to >>> prevent >>> the use of C++ libraries in the VM. It destroys the simulator, which is >>> the most important thing we have for VM development productivity. As far >>> as I'm concerned any use of external libraries to implement core >>> functionality kills the VM-in-Smalltalk concept that Squeak (and Pharo) >>> are >>> built upon. >>> >>> >>> OK, I defer to you because you certainly know more about the VM internals >>> and what does and doesn't work well than anyone else. >>> >>> So I guess I would like to know your recommendation for 1) how best to >>> store strings - byte arrays (UTF8), - 2-byte word arrays (UTF16 - now we >>> get to worry about endian). >>> >> >> Raw Unicode, either as 8-bit, 16-bit or 32-bit. When creating a String it >> should start as an 8-bit-per-Unicode-character string. Attempts to store >> Character values that won't fit cause the String to become a String whose >> element size is large enough to accommodate the character. > > This is the case: see tests here http://wiki.squeak.org/squeak/6316 > > In Spur, >> become: is cheap so this growth pays only for the reallocation and copying >> of the at a, not for an expensive heap scan necessary to do the become:. > > Could you elaborate on this please? https://hal.inria.fr/hal-01152610/file/partialReadBarrier.pdf cheers -ben >> >> >>> Bearing in mind that both representations are variable length and so >>> while >>> accessing the n'th byte/word is O(1), accessing the n'th character is >>> necessarily O(n) unless you know you have no surrogates in your string. >>> >> >> Right, so UTF-8 and UTF-16 are not convenient representations and to be >> provided only for interchange. > > +1 > > Squeak/Pharo uses 8bit/32bit (UTF-32) internally and UTF-8 externally. > There are converters for UTF-8 and UTF-16. > > > >> >>> >>> Also...since NSString has been mentioned...it is worth noting that >>> NSString is built atop CFString (source code here: >>> https://www.opensource.apple.com/source/CF/CF-855.11/CFString.c) which >>> does a fair job of optimizing memory by using bytes where it can and >>> shorts >>> where it cannot. It is also worth noting that characterAt: actually does >>> the wrong thing, since it assumes characters are no bigger than FFFF >>> rather >>> than 10FFFF. >>> >> >> Yes, and Squeak (and AFAIA, Pharo) has been doing this for ages. If one >> has become: it is very easy to manage. Now with Spur not only do we have >> become:, we have a fairly fast become:. >> >> Does this make sense? >> >> >>> Also...I'll just toss in this very nice article on unicode and how >>> NSString deals with it. >>> https://www.objc.io/issues/9-strings/unicode/ >>> >>> -Todd Blanchard >>> >> >> _,,,^..^,,,_ >> best, Eliot >>

Dec. 16, 2015

Re: [Pharo-dev] [Moose-dev] Where to get Spur?

by Esteban Lorenzano

> On 16 Dec 2015, at 12:01, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> I will update the links in the pharo page as soon as I have resumed the CI process. > > Ok. This is importantâ¦ done > > Cheers, > Alexandre > >> >> Esteban >> >>> On 16 Dec 2015, at 11:47, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>> Hi! >>> >>> The Pharo 5.0 (and therefore Moose) cannot be open with the last VM available on pharo.org. >>> I think that if the image can only be run on Spur, Spur should be available. >>> >>> So, where to get Spur? >>> Here: ? >>> https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/375/Architect… >>> >>> I have tried Roassal on Spur, and text cannot be displayed properly. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Dec. 16, 2015

Re: [Pharo-dev] [Moose-dev] Where to get Spur?

by Alexandre Bergel

> I will update the links in the pharo page as soon as I have resumed the CI process. Ok. This is importantâ¦ Cheers, Alexandre > > Esteban > >> On 16 Dec 2015, at 11:47, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> Hi! >> >> The Pharo 5.0 (and therefore Moose) cannot be open with the last VM available on pharo.org. >> I think that if the image can only be run on Spur, Spur should be available. >> >> So, where to get Spur? >> Here: ? >> https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/375/Architect… >> >> I have tried Roassal on Spur, and text cannot be displayed properly. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 16, 2015

Re: [Pharo-dev] [Moose-dev] Where to get Spur?

by Esteban Lorenzano

wget -O- get.pharo.org/50+vm <http://get.pharo.org/50+vm> wget -O- get.pharo.org/vm50 <http://get.pharo.org/vm50> wget -O- get.pharo.org/50 <http://get.pharo.org/50> zeroconf already downloads correct VM :) files.pharo.org/vm/pharo-spur32 <http://files.pharo.org/vm/pharo-spur32> has the compiled VMs I will update the links in the pharo page as soon as I have resumed the CI process. Esteban > On 16 Dec 2015, at 11:47, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi! > > The Pharo 5.0 (and therefore Moose) cannot be open with the last VM available on pharo.org. > I think that if the image can only be run on Spur, Spur should be available. > > So, where to get Spur? > Here: ? > https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/375/Architect… > > I have tried Roassal on Spur, and text cannot be displayed properly. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Dec. 16, 2015

Where to get Spur?

by Alexandre Bergel

Hi! The Pharo 5.0 (and therefore Moose) cannot be open with the last VM available on pharo.org. I think that if the image can only be run on Spur, Spur should be available. So, where to get Spur? Here: ? https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/375/Architect… I have tried Roassal on Spur, and text cannot be displayed properly. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 16, 2015

[pharo-project/pharo-core]

by GitHub

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

Dec. 16, 2015

[pharo-project/pharo-core] 7ef1c1: 50501

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 7ef1c11d40b09591a37608e90f1e1f20c3e46a37 https://github.com/pharo-project/pharo-core/commit/7ef1c11d40b09591a37608e9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-16 (Wed, 16 Dec 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50500.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50501.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50500.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50501.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A StartupPreferences.package/StartupPreferencesLoader.class/class/as yet unclassified/cleanUp_.st Log Message: ----------- 50501 17247 clean dirty slot packages (spur migration) https://pharo.fogbugz.com/f/cases/17247 17248 integrate FFI-NB changes on System packages (spur migration) https://pharo.fogbugz.com/f/cases/17248 17245 clean dirty collection packages (spur migration) https://pharo.fogbugz.com/f/cases/17245 17246 clean dirty fuel packages (spur migration) https://pharo.fogbugz.com/f/cases/17246 17244 Startup scripts should be reset on cleanUp https://pharo.fogbugz.com/f/cases/17244 http://files.pharo.org/image/50/50501.zip

Dec. 16, 2015

Re: [Pharo-dev] AsmJit

by Henrik Johansen

> On 16 Dec 2015, at 6:48 , ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > 2015-12-15 20:22 GMT+01:00 Jan Vrany <jan.vrany(a)fit.cvut.cz <mailto:jan.vrany@fit.cvut.cz>>: > Hi Esteban, Eliot, Clemont > > thanks very much for elaborate answer. I'm aware of all what you said > (well, most :-), but my actual needs are very low and primitive. > > All I need now is something that allows me to turn x86_64 assembly > into a machine code using a sane Smalltalk API, which I can later copy > to VM code space. Nothing more, nothing less :-) I do not fancy > spending time writing yet-another-x86-assembler hence my interest in > asmjit. > > As far as I know AsmJIT has stable support for x86 but not x86_64 There's no x86_64 VM to test on yet, so obviously the support is only theoretical. Removing the option of executing emitted bytes in the first place in any x86_64 VM released, just makes that a self-fulfilling prophecy. There *are* tests that correct x86_64 instructions are emitted for a large number of operations, but by no means all of them. In other words, emitting x86_64 machine code with a sane Smalltalk API is a use case already somewhat supported (imho). There's a chicken-and-egg kind of the problem; you don't even want to start coding NB support before you have a platform to run on; which again means, you *cannot* rely on it to get a base image up and running. After Spur images are actually released, creating support for interacting with the new image format / VM probably probably wouldn't be too much work, nor getting x86_64 to a better state wrt. emitting correct instructions. Though, I guess for the worried, in order to have it included in a general release, you would need to rewrite the NB primitive to - Provide validation along the lines of NaCl - Store/Execute validated machine code in/from a restricted space, rather than in method trailers which means none of the above will ever happen. The main pain points in image-side programming are support for other instruction sets to the same level of completeness as AsmJIT is for x86/x64, and implementing new ABI's for FFI (which, after all, is what *most* people seem to use NB for). All of which add up to making Sista bytecodes a less exiting, but more reasonable alternative. Cheers, Henry

Dec. 16, 2015