- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Moving from mc to tonel?

by Peter UhnÃ¡k

> I suspect it's related to the large number of commits in my repo. I made > some tweaks and succeeded to create the fast-import file. But I get: > All files in a single commit will be held temporarily in MemoryStore, so unless you have GBs of code in _single_ commit it shouldn't be a problem. There's also a possiblity that Pharo was going too fast and didn't manage to GC it in time or there's a memory leak. > > fatal: Unsupported command: . > fast-import: dumping crash report to .git/fast_import_crash_10301 > > Do you recognize this error? > Please look into the mentioned file, it should give you a context for the error (and then you can look into the import file around the same context). Peter

Dec. 5, 2017

Re: [Pharo-dev] Moving from mc to tonel?

by Sven Van Caekenberghe

> On 5 Dec 2017, at 08:34, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > On 5 December 2017 at 03:41, Martin Dias <tinchodias(a)gmail.com> wrote: >> I suspect it's related to the large number of commits in my repo. I made >> some tweaks and succeeded to create the fast-import file. But I get: >> >> fatal: Unsupported command: . >> fast-import: dumping crash report to .git/fast_import_crash_10301 >> >> Do you recognize this error? >> I will check my changes tweaking the git-migration tool to see if I modified >> some behavior my mistake... > > I had the same error just last night. > > In my case, it turned out to be a non-UTF8 encoded character in one of > the commit messages. > > I tracked it down by looking at the crash report and searching for a > nearby command. I've deleted the crash reports now, but I think it > was the number associated with a mark command that got me near the > problem character in the fast-import file. > > I also modified the code to halt whenever it found a non-UTF8 > character. I'm sure there are better ways to do this, but: > > > GitMigrationCommitInfo>>inlineDataFor: aString > > | theString | > theString := aString. > "Ensure the message has valid UTF-8 encoding (this will raise an > error if it doesn't)" > [ (ZnCharacterEncoder newForEncoding: 'utf8') decodeBytes: aString > asByteArray ] > on: Error > do: [ :ex | self halt: 'Illegal string encoding'. > theString := aString select: [ :each | each asciiValue > between: 32 and: 128 ] ]. > ^ 'data ' , theString size asString , String cr , (theString > ifEmpty: [ '' ] ifNotEmpty: [ theString , String cr ]) There is also ByteArray>>#utf8Decoded (as well as String>>#utf8Encoded), both using the newer ZnCharacterEncoders. So you could write it shorter as: aString asByteArray utf8Decoded Instead of Error you could use the more intention revealing ZnCharacterEncodingError. Apart from that, and I known you did not create this mess, encoding a String into a String, although it can be done, is so wrong. You encode a String (a collection of Characters, of Unicode code points) into a ByteArray and you decode a ByteArray into a String. Sending #asByteArray to a String in almost always wrong, as is sending #asString to a ByteArray. These are implicit conversions (null conversions, like ZnNullEncoder) that only work for pure ASCII or Latin1 (iso-8859-1), but not for the much richer set of Characters that Pharo supports. So these will eventually fail, one day, in a country far away. > Cheers, > Alistair >

Dec. 5, 2017

Re: [Pharo-dev] Moving from mc to tonel?

by Alistair Grant

On 5 December 2017 at 03:41, Martin Dias <tinchodias(a)gmail.com> wrote: > I suspect it's related to the large number of commits in my repo. I made > some tweaks and succeeded to create the fast-import file. But I get: > > fatal: Unsupported command: . > fast-import: dumping crash report to .git/fast_import_crash_10301 > > Do you recognize this error? > I will check my changes tweaking the git-migration tool to see if I modified > some behavior my mistake... I had the same error just last night. In my case, it turned out to be a non-UTF8 encoded character in one of the commit messages. I tracked it down by looking at the crash report and searching for a nearby command. I've deleted the crash reports now, but I think it was the number associated with a mark command that got me near the problem character in the fast-import file. I also modified the code to halt whenever it found a non-UTF8 character. I'm sure there are better ways to do this, but: GitMigrationCommitInfo>>inlineDataFor: aString | theString | theString := aString. "Ensure the message has valid UTF-8 encoding (this will raise an error if it doesn't)" [ (ZnCharacterEncoder newForEncoding: 'utf8') decodeBytes: aString asByteArray ] on: Error do: [ :ex | self halt: 'Illegal string encoding'. theString := aString select: [ :each | each asciiValue between: 32 and: 128 ] ]. ^ 'data ' , theString size asString , String cr , (theString ifEmpty: [ '' ] ifNotEmpty: [ theString , String cr ]) Cheers, Alistair

Dec. 5, 2017

Re: [Pharo-dev] Pharo newsletter archive

by Tudor Girba

+1 Doru > On Dec 5, 2017, at 7:54 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Yes good idea! > Tx > > On Mon, Dec 4, 2017 at 7:52 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> Hi, >> >> the newsletter archive is now available on >> >> "newsletter.pharo.org" >> >> which is more easy to remember. >> >> Thanks Marcus for setting up the redirect! >> >> Bye >> T. >> > -- www.tudorgirba.com www.feenk.com "When people care, great things can happen."

Dec. 5, 2017

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo TechTalk 21 Nov: Discord Demo

by Tudor Girba

Thanks! Doru > On Nov 23, 2017, at 8:26 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > Hi, the new version is available here: https://www.youtube.com/watch?v=y1EzOnfHUe0 > > Hopefully it helps :-) > Juraj > >> On Nov 22, 2017, at 15:45, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Juraj Kubelka wrote >>> I will upload recording I have on my computer. It is clear. >> >> Thanks! >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > -- www.tudorgirba.com www.feenk.com "Value is always contextual."

Dec. 5, 2017

Re: [Pharo-dev] Pharo newsletter archive

by Stephane Ducasse

Yes good idea! Tx On Mon, Dec 4, 2017 at 7:52 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > the newsletter archive is now available on > > "newsletter.pharo.org" > > which is more easy to remember. > > Thanks Marcus for setting up the redirect! > > Bye > T. >

Dec. 5, 2017

Re: [Pharo-dev] Moving from mc to tonel?

by Martin Dias

I suspect it's related to the large number of commits in my repo. I made some tweaks and succeeded to create the fast-import file. But I get: fatal: Unsupported command: . fast-import: dumping crash report to .git/fast_import_crash_10301 Do you recognize this error? I will check my changes tweaking the git-migration tool to see if I modified some behavior my mistake... cheers, MartÃn On Fri, Dec 1, 2017 at 1:42 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Julien, I dodn't know it but anyway my issue was just in the step > smalltalkhub -> filtree using the migration tool. > > Peter, yes it's public. This is the code I used: > > ---------------------------------------- > > migration := GitMigration on: 'MartinDias/Epicea'. > migration cacheAllVersions. > migration authors: { > 'md' -> #('Martin Dias' '<tinchodias(a)gmail.com>'). > 'MD' -> #('Martin Dias' '<tinchodias(a)gmail.com>'). > 'MartinDias' -> #('Martin Dias' '<tinchodias(a)gmail.com>'). > 'PabloTesone' -> #('Pablo Tesone' '<tesonep(a)gmail.com>'). > 'PavelKrivanek' -> #('Pavel Krivanek' '<pavel.krivanek(a)gmail.com>'). > 'DamienCassou' -> #('Damien Cassou' '<DamienCassou(a)gmail.com>'). > 'DenisKudryashov' -> #('Denis Kudryashov' '<dionisiydk(a)gmail.com>'). > 'GustavoSantos' -> #('Gustavo Santos' '<gugajansen(a)gmail.com>'). > 'ThomasHeniart' -> #('Thomas Heniart' '<heniart.thomas(a)gmail.com>'). > 'LucasGodoy' -> #('Lucas Godoy' '<godoy.lucas(a)gmail.com>'). > 'StephaneDucasse' -> #('Stephane Ducasse' '<stephane.ducasse(a)inria.fr>'). > 'VincentBlondeau' -> #('Vincent Blondeau' '<vincent.blondeau(a)inria.fr>'). > 'AlbertoBacchelli' -> #('Alberto Bacchelli' '<sbackg(a)gmail.com>'). > 'SkipLentz' -> #('Skip Lentz' '<skippetie(a)gmail.com>'). > 'TheIntegrator' -> #('The Integrator' '<integrator(a)fake.com>'). > }.l > migration > fastImportCodeToDirectory: 'src' > initialCommit: '18a30d8d' > to: './epicea-fast-import.txt' > > ---------------------- > > MartÃn > > On Thu, Nov 30, 2017 at 2:14 PM, Julien <julien.delplanque(a)inria.fr> > wrote: > >> If you use Traits and want to have Epicea loadable from GitHub on Pharo >> 6.1, it will not work. >> >> There is an issue when you try to load a Trait in Tonel format in the >> image. >> >> --- >> Julien Delplanque >> Doctorant Ã lâUniversitÃ© de Lille 1 >> http://juliendelplanque.be/phd.html >> Equipe Rmod, Inria >> BÃ¢timent B 40, avenue Halley 59650 >> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve%C2%A0d'Ascq&entry=gmail&source=g> >> Villeneuve >> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve%C2%A0d'Ascq&entry=gmail&source=g> >> d'Ascq >> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve%C2%A0d'Ascq&entry=gmail&source=g> >> NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 >> >> Le 6 nov. 2017 Ã 01:42, Martin Dias <tinchodias(a)gmail.com> a Ã©crit : >> >> Hi all, I'm considering to move Epicea (+Ombu+Hiedra) to github. I read >> that tonel is the new format and there is Peter's git-migration, which >> could be the tool to do it. >> >> Is it good idea to move now? >> Is it the right tool? >> >> Bests, >> MartÃn >> >> >> >

Dec. 5, 2017

Re: [Pharo-dev] [Vm-dev] Garbage Collection (was Re: Discussing the roadmap)

by Ben Coman

Hi Eliot, On 4 December 2017 at 23:44, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Alas a forwarding object has two fields that need to be set in separate words. > The class index in the header must be the forwarder class index, > and the first word of the object body must point to the forwarder. Good to better understand that. Just restating after condensing most of the thread, only the Main-thread would convert objects to forwarders. > Reverting obviously requires two writes too. So atomic (un)forwarding is not possible. sorry, just double-checking since I realised I erred in my example below, which may have mislead your response. IIUC(now)... while "creating" a forwarder involves writing separately to object-header and object-body. wouldn't "reverting" only involve updating an object-pointer in a slot to the real-object's new location? And that would be a single word operation on both 32bit and 64bit platforms? > >> - Currently the marking phase removes all forwarders and I would like incremental marking to maintain the same invariant (forwarders are always white). > > > > A concurrent-marking thread could essentially do the same. > > i. From shared memory load forward header Fh from object-slot > > Fheader <== object-slot > > ii. Follow forwarder to real-object, store into local temporary > > Rheader <== flattened/followed pointer > > > > iii. Atomic compare-and-swap R back into object-slot, > > object-slot <== if Fheader then Rheader whoops, corrected... i. From shared memory, concurrent marking-scan has loaded an object-pointer from object-slot. If it points to a forwarding object ... Opointer <== object-slot (as part of normal marking scan) if *Opointer isForwardingObject { Fpointer <== Opointer (redundant, just for clarity) ii. Follow that to real-object, store into local temporary Rpointer <== followed Fpointer forwarding chain to real object. iii. Atomic compare-and-swap Rpointer back into object-slot object-slot <== if still Fpointer then Rpointer When (iii.) fails * If I'm the Main-thread, I'm in the middle of handling a failed forwarder-check and can infer the GC-thread already did what I was going to do. I can be certain that... "object-slot == Rpointer" (since thats the only object-slot mutation GC-threads can do) so its fine to continue to my usual post-flattening retry * If I'm a GC-thread, either: * the Main-thread flattened the forwarder, or * the Main-thread changed which object the slot holds In either case, just re-read the slot A race scenario to consider is where the Main-thread converts an object to a forwarder simultaneous with a GC-thread flattening one of its slots. The object copy in its new location may miss that update. But in terms of the object graph that seems not a problem, since the copy without that update is still consistent. Infrequently just a little bit of work is lost. I'm contemplating other race scenarios around marking, but won't distract with them for now. cheers -ben

Dec. 5, 2017

Re: [Pharo-dev] Bloc Feedback

by Ben Coman

On 5 December 2017 at 05:19, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi Aliaksei > > Read again this sentence :) > > "BlPostAction" - a valuable that is guaranteed to be evaluated in the > beginning of every frame before anything else. > > MAy be BlPostAction should be renamed BlEarlyAction > BlPreAction > > > > On Sat, Dec 2, 2017 at 5:26 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > > Hi, > > > > An object that is called now "Animation" in Bloc is not necessarily > bound to > > the visual element. > > The correct name for the root class of "BlBaseAnimation" should be > > "BlPostAction" - a valuable that is guaranteed to be evaluated in the > > beginning of every frame before anything else. We have already a deferred > > action but they are only evaluated when there is enough time between > frames. > > "BlBaseAnimation" should be renamed to something line > "BlElementAnimation" > > that is guaranteed to be bound to a visual element and stops itself if > > element is no more in the scene graph by checking that explicitly before > > doing every animation step. > > > > Cheers, > > Alex > > > > On 2 December 2017 at 16:35, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> > >> Aliaksei Syrel wrote > >> > ... > >> > Also, what is the lifetime of an infinite animation? > >> > ... > >> > Do you have any particular use-case for animations? > >> > >> I hacked together a simplified stepping animation (may not be in the > right > >> place in the class hierarchy). Here's a pull request to discuss > >> https://github.com/pharo-graphics/Bloc/pull/37 > >> > >> > >> > >> ----- > >> Cheers, > >> Sean > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > >> > > > >

Dec. 4, 2017

Re: [Pharo-dev] Polymorphism between Strings and FileReference

by Stephane Ducasse

To me stringOfFileReference is a bad smell. On Fri, Dec 1, 2017 at 12:04 PM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > On Fri, Dec 1, 2017 at 11:55 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> Hi Cyril, >> >> The normal way to handle this is #asFileReference, so you can just have: >> >> aStringOrReference asFileReference readStreamDo: ... >> > > In that case, if it is a String like 'test', we will get a readStream > on the file './test' and not on the string 'test'. This is not what I > want. > > What I want is this for example: > > > > MyClass>>addComaAtTheEndOf: aStringOrFileReference > "If the argument is a String, add a coma at the end. If the > parameter is a file, add a coma at the end of its contents" > > aStringOrFileReference writeStreamDo: [ :s | s atEnd; nextPut: $, ] > > > > If I use your code, it will not add a coma at the end of the string > parameter, but at the end of the file represented by the string if it > exists. > >> Cheers, >> Alistair >> > > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Dec. 4, 2017