- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Tudor Girba

Hi, The basic tools, such as debugger, are expected to work. If something does not work, itâs a bug. Cheers, Doru > On Nov 8, 2017, at 11:59 PM, Tim Mackinnon <tim(a)testit.works> wrote: > > I think it's broken in Pharo 6 too, as I often find it unreliable. > > It's hard to know what should work anymore - we really need a stabilisation release to let the dust settle. > > I'm always a bit reticent to report things as I'm not sure what you expect to work. > > Tim > > Sent from my iPhone > >> On 8 Nov 2017, at 20:40, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi >> >> I have the following method and I have my cursor -MY CURSOR HERE- >> I select the menu run to here and .... I exit the method. >> :( >> >> Is run to here working in Pharo 70? >> I start to get worry about the number of bugs I get when using Pharo70. >> >> Stef >> >> >> fileOut >> "File out the receiver, to a file whose name is a function of the >> change-set name and a unique numeric tag." >> >> | nameToUse | >> self halt. >> self class promptForDefaultChangeSetDirectoryIfNecessary. >> nameToUse := (self defaultChangeSetDirectory / self name , 'cs') >> nextVersion basename. >> UIManager default >> showWaitCursorWhile: >> [ >> | internalStream | >> internalStream := (String new: 10000) writeStream. >> >> -MY CURSOR HERE- >> >> internalStream >> header; >> timeStamp. >> self fileOutPreambleOn: internalStream. >> self fileOutOn: internalStream. >> self fileOutPostscriptOn: internalStream. >> CodeExporter >> writeSourceCodeFrom: internalStream >> baseName: (nameToUse copyFrom: 1 to: nameToUse size - 3) >> isSt: false ] >> > > -- www.tudorgirba.com www.feenk.com "Value is always contextual."

Nov. 9, 2017

Re: [Pharo-dev] about SortFunctions

by Todd Blanchard

Which is weird because I think the magic is its decentralized nature. > On Nov 6, 2017, at 1:52 PM, Ben Coman <btc(a)openinworld.com> wrote: > > Some would say it was github that "made" git (popular).

Nov. 9, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Nicolas Cellier

2017-11-09 0:52 GMT+01:00 Martin McClure <martin(a)hand2mouse.com>: > On 11/08/2017 01:15 PM, Sven Van Caekenberghe wrote: > >> What is the opinion of the original Tonel designers ? >> > > Well, Esteban did the largest part of the work, but I guess I am *one* of > the original designers, in that various design proposals were floated back > and forth, starting with one of mine and ending with Tonel. > > My intent is that Tonel, as a declarative cross-platform format, should > use strings exclusively, never Symbols. I *think* I discussed this with > Esteban during ESUG, and I *think* he agreed, so it seems likely that the > current behavior with class definitions is unintentional. > > Regards, > > -Martin > > > Ah you remind me there's one thing I don't like in this format: Tonel must be aware of all possible syntax tricks in order to parse the method body... And that ain't easy https://pharo.fogbugz.com/f/cases/20659/Tonel-parser-is-broken-by-literal-a… I found that while accidentally reading the code due to https://pharo.fogbugz.com/f/cases/20652/Iceberg-branch-compare-bug

Nov. 9, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Martin McClure

On 11/08/2017 01:15 PM, Sven Van Caekenberghe wrote: > What is the opinion of the original Tonel designers ? Well, Esteban did the largest part of the work, but I guess I am *one* of the original designers, in that various design proposals were floated back and forth, starting with one of mine and ending with Tonel. My intent is that Tonel, as a declarative cross-platform format, should use strings exclusively, never Symbols. I *think* I discussed this with Esteban during ESUG, and I *think* he agreed, so it seems likely that the current behavior with class definitions is unintentional. Regards, -Martin

Nov. 8, 2017

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Tim Mackinnon

I think it's broken in Pharo 6 too, as I often find it unreliable. It's hard to know what should work anymore - we really need a stabilisation release to let the dust settle. I'm always a bit reticent to report things as I'm not sure what you expect to work. Tim Sent from my iPhone > On 8 Nov 2017, at 20:40, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi > > I have the following method and I have my cursor -MY CURSOR HERE- > I select the menu run to here and .... I exit the method. > :( > > Is run to here working in Pharo 70? > I start to get worry about the number of bugs I get when using Pharo70. > > Stef > > > fileOut > "File out the receiver, to a file whose name is a function of the > change-set name and a unique numeric tag." > > | nameToUse | > self halt. > self class promptForDefaultChangeSetDirectoryIfNecessary. > nameToUse := (self defaultChangeSetDirectory / self name , 'cs') > nextVersion basename. > UIManager default > showWaitCursorWhile: > [ > | internalStream | > internalStream := (String new: 10000) writeStream. > > -MY CURSOR HERE- > > internalStream > header; > timeStamp. > self fileOutPreambleOn: internalStream. > self fileOutOn: internalStream. > self fileOutPostscriptOn: internalStream. > CodeExporter > writeSourceCodeFrom: internalStream > baseName: (nameToUse copyFrom: 1 to: nameToUse size - 3) > isSt: false ] >

Nov. 8, 2017

Re: [Pharo-dev] ExternalAddress uniqueness (was Re: Call for help for stability and rewrite of FreeType)

by Nicolas Cellier

I don't know this part neither, just did what every other C developer would do: RTFM, fail to interpret TFM, RTFM again and think. 2017-11-08 22:56 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Thanks for your deep dive on this Nicolas. > I'm not familiar with that part of the system, and its interesting to read > about the interface constraints. > > cheers -ben > > > On Wed, Nov 8, 2017 at 11:40 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> >> 2017-11-08 16:10 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com>: >> >>> >>> >>> 2017-11-08 15:35 GMT+01:00 Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>> >>>> >>>> 2017-11-08 14:53 GMT+01:00 Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com>: >>>> >>>>> >>>>> >>>>> 2017-11-08 14:42 GMT+01:00 Nicolas Cellier < >>>>> nicolas.cellier.aka.nice(a)gmail.com>: >>>>> >>>>>> >>>>>> Ben, >>>>>> >>>>>> This is my fresh crash.dmp >>>>>> it sounds very related to your analysis!!! >>>>>> >>>>>> In fact we are not freeing by ourselves, but telling libgit2 to do >>>>>> it... >>>>>> >>>>>> >>>>> Oh worse than that, it sounds like git implemented its own mechanism >>>>> of counted pointers... >>>>> So we don't tell anything, he guesses by himself. >>>>> I would search for places where we #gcallocate: or manually #free a >>>>> pointer on a structure passed back by git... >>>>> >>>>> >>>> and of course, it's not gcallocate: because this was a very old wheel... >>>> It's rather somewhere in UFFI equivalent >>>> FFIExternalResourceExecutor <- FFIExternalResourceManager <- >>>> LGitExternalStructure autoRelease >>>> >>>> Among the senders, we see (tiens, tiens...): >>>> LGitTree>>... >>>> >>>> So this is where I would search the origin of my own crash dump... >>>> >>>> But also (tiens, tiens...): >>>> CairoFontFace>>initializeWithFreetypeFace: >>>> >>>> What if FreeType plugin was not the problem per se, but its usage in >>>> cairo was? >>>> >>>> cairo_font_face_destroy () >>>> void cairo_font_face_destroy >>>> (cairo_font_face_t *font_face); >>>> Decreases the reference count on font_face by one. If the result is >>>> zero, *then font_face and all associated resources are freed*. See >>>> cairo_font_face_reference(). >>>> font_face : >>>> a cairo_font_face_t >>>> >>>> Since we pass a pointer to the free type font at creation: >>>> >>>> fromFreetypeFace: aFace >>>> | handle cairoFace | >>>> handle := aFace handle pointerAt: 1. >>>> cairoFace := self primFtFace: handle loadFlags: ( LoadNoHinting | >>>> LoadTargetLCD | LoadNoAutohint | LoadNoBitmap). >>>> ^ cairoFace initializeWithFreetypeFace: aFace >>>> >>>> Isn't it possible that we somehow double free the free type font too? >>>> >>>> >>> Hmm not the exact catch but it could well be related >>> >>> https://www.cairographics.org/manual/cairo-FreeType-Fonts.html tells >>> how to couple lifetime of the 2 data structures. >>> I see that CairoFontFace retains a pointer on the FT_Face thru a >>> dedicated ivar, so at least, we don't free the FT_Face twice, and we don't >>> free it until we free the cairo_ft_face >>> >>> When finalizatoin occurs, I'm not sure that the finalization order is >>> guaranteed but that does not matter. >>> What matters is that the cairo_ft_face could still be referenced >>> internally by cairo. >>> >>> So what can happen is that: >>> 1) we don't reference anymore the CairoFontFace from within Smalltalk >>> 2) finalization happens we call cairo_font_face_destroy () >>> 3) there is no more pointer on the FTFace from within Smalltalk (because >>> we just reclaimed the CairoFontFace pointing on it) >>> 4) finalization happens and we call FT_Done_Face() >>> >>> BUT: cairo was still using the cairo_font_face internally, (the >>> reference count did not reach zero) and is now pointing on freed memory due >>> to FT_Done_Face()... >>> >>> We should have tested the status before invoking FT_Done(): >>> >>> status = cairo_font_face_set_user_data (font_face, &key, >>> ft_face, (cairo_destroy_func_t) FT_Done_Face); >>> >>> That means that we would have to performa that status test in the >>> finalization, and if not ready, keep a reference to both cairo_font_face >>> handle ft_face handle >>> But then there is no other mean than storing those reference in a safe >>> place and regularly poll for readiness >>> If my understanding is correct, this is absolutely garbage collector >>> unfriendly! >>> >>> >> No total misunderstanding from my side... >> by setting the user data and destroy function, we are asking to >> auto-release the ft_face >> In which case, it's bad, because the ft_face is not ref-counted and we >> might still have another pointer on it from within Smalltalk >> >> The only way is thus to poll thru: >> >> cairo_font_face_get_reference_count (*cairo_font_face_t <https://www.cairographics.org/manual/cairo-cairo-font-face-t.html#cairo-fon…> *font_face*); >> >> If the count is 1, we can safely proceed with finalization. >> Else, there is still an internal reference somewhere in cairo and bang! >> >> I'd suggest to instrument the code with this function: >> >> CairoFontFace class>>countReferences: handle >> " >> unsigned int cairo_font_face_get_reference_count >> (cairo_font_face_t *font_face); >> " >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >> errorCode> >> ^ self nbCall: #( unsigned int cairo_font_face_get_reference_count >> (size_t handle)) >> >> >> CairoFontFace class>>reallyFinalizeResourceData: handle >> " >> void cairo_font_face_destroy >> (cairo_font_face_t *font_face); >> " >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >> errorCode> >> ^ self nbCall: #( void cairo_font_face_destroy (size_t handle)) >> >> CairoFontFace class>>finalizeResourceData: handle >> (self countReferences: handle) = 1 ifFalse: [self halt: 'Houston, >> we gonna have a pointer reference problem']. >> ^self reallyFinalizeResourceData: handle >> >> If suspicion is confirmed, then we'll have to install the ref_count >> polling mechanism... >> >> >> >>>> >>>>>> Stack backtrace: >>>>>> [7791E43E] RtlInitializeGenericTable + 0x196 in ntdll.dll >>>>>> [7791E0A3] RtlGetCompressionWorkSpaceSize + 0x7e in ntdll.dll >>>>>> [751F98CD] free + 0x39 in msvcrt.dll >>>>>> [6CD60D43] git_tree_cache_write + 0x2ac in libgit2.dll >>>>>> [6CD62073] git_tree__free + 0x53 in libgit2.dll >>>>>> [6CD1A563] git_object__free + 0x52 in libgit2.dll >>>>>> [6CCD0D78] git_cached_obj_decref + 0x4c in libgit2.dll >>>>>> [6CD1A7D9] git_object_free + 0x17 in libgit2.dll >>>>>> [6CD1B0D3] git_tree_free + 0x11 in libgit2.dll >>>>>> [6CD0BE4F] git_iterator_for_nothing + 0x8aa in libgit2.dll >>>>>> [6CD0C053] git_iterator_for_nothing + 0xaae in libgit2.dll >>>>>> [6CCEADEF] git_diff_file_content__clear + 0x31d in libgit2.dll >>>>>> [6CCECC3F] git_diff__oid_for_entry + 0xc29 in libgit2.dll >>>>>> [6CCED2B2] git_diff__oid_for_entry + 0x129c in libgit2.dll >>>>>> [6CCED495] git_diff__from_iterators + 0x1db in libgit2.dll >>>>>> [6CCED6DE] git_diff_tree_to_tree + 0x1e3 in libgit2.dll >>>>>> [004DE7C8] ??? + 0xde7c8 in Pharo.exe >>>>>> [0044FE08] ??? + 0x4fe08 in Pharo.exe >>>>>> [004516A7] ??? + 0x516a7 in Pharo.exe >>>>>> [00446051] ??? + 0x46051 in Pharo.exe >>>>>> [0049936E] ??? + 0x9936e in Pharo.exe >>>>>> >>>>>> >>>>>> Smalltalk stack dump: >>>>>> 0xafa86c I LGitDiff>diff_tree_to_tree:repo:old_tree:new_tree:opts: >>>>>> 0xe585410: a(n) LGitDiff >>>>>> 0xafa8a4 M [] in LGitDiff>diffTree:toTree:options: 0xe585410: a(n) >>>>>> LGitDiff >>>>>> 0xafa8bc M LGitDiff(LGitExternalObject)>withReturnHandlerDo: >>>>>> 0xe585410: a(n) LGitDiff >>>>>> 0xafc678 I LGitDiff>diffTree:toTree:options: 0xe585410: a(n) >>>>>> LGitDiff >>>>>> 0xafc6a4 I LGitDiff>diffTree:toTree: 0xe585410: a(n) LGitDiff >>>>>> 0xafc6d0 I LGitTree>diffTo: 0xe583e00: a(n) LGitTree >>>>>> 0xafc6fc M [] in IceLibgitLocalRepository>changedFilesBetween:and: >>>>>> 0x1055afc0: a(n) IceLibgitLocalRepository >>>>>> 0xafc720 M [] in IceLibgitLocalRepository>withRepoDo: 0x1055afc0: >>>>>> a(n) IceLibgitLocalRepository >>>>>> 0xafc73c M [] in LGitGlobal class>runSequence: 0xfb96188: a(n) >>>>>> LGitGlobal class >>>>>> 0xafc760 M [] in LGitActionSequence(DynamicVariable)>value:during: >>>>>> 0x102109f8: a(n) LGitActionSequence >>>>>> 0xafc780 M BlockClosure>ensure: 0xe582890: a(n) BlockClosure >>>>>> 0xafc7ac I LGitActionSequence(DynamicVariable)>value:during: >>>>>> 0x102109f8: a(n) LGitActionSequence >>>>>> 0xafc7cc M LGitActionSequence class(DynamicVariable >>>>>> class)>value:during: 0xfbb81e0: a(n) LGitActionSequence class >>>>>> 0xafc7f4 I LGitGlobal class>runSequence: 0xfb96188: a(n) LGitGlobal >>>>>> class >>>>>> 0xafc818 I IceLibgitLocalRepository>withRepoDo: 0x1055afc0: a(n) >>>>>> IceLibgitLocalRepository >>>>>> 0xafc840 I IceLibgitLocalRepository>changedFilesBetween:and: >>>>>> 0x1055afc0: a(n) IceLibgitLocalRepository >>>>>> 0xafc874 I IceCommitInfo>changedPackagesToCommitInfo: 0x113b80e0: >>>>>> a(n) IceCommitInfo >>>>>> 0xafc898 I IceCommitInfo>changedPackagesTo: 0x113b80e0: a(n) >>>>>> IceCommitInfo >>>>>> 0xafc8c0 I IceDiff>initialElements 0xe4c48f8: a(n) IceDiff >>>>>> 0xaf9664 I IceDiff(IceAbstractDiff)>elements 0xe4c48f8: a(n) >>>>>> IceDiff >>>>>> 0xaf9684 I IceDiffChangeTreeBuilder>elements 0xe4b9c80: a(n) >>>>>> IceDiffChangeTreeBuilder >>>>>> 0xaf969c M [] in IceDiffChangeTreeBuilder>buildOn: 0xe4b9c80: a(n) >>>>>> IceDiffChangeTreeBuilder >>>>>> >>>>>> Dimitris: >>>>>> >>>>>> I won't argument, I've learnt C in 1987, so it gave me enough time to >>>>>> learn my own limits. >>>>>> Working with pointers is like carrying a gun without engaging the >>>>>> safety catch. >>>>>> I came to think that shooting own foot was a feature ;) >>>>>> >>>>>> 2017-11-06 11:04 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >>>>>> >>>>>>> Its the usual case of not being able to have your cake and eat it >>>>>>> too. >>>>>>> >>>>>>> If you want top performance you have to manage memory yourself plus >>>>>>> the abilitiy to access thousands of C libraries is not such a bad excuse >>>>>>> for a compromise. The FFI is not a problem is a solution to many problems >>>>>>> and people using it its not as if Smalltalk offers them any alternative >>>>>>> choice. >>>>>>> >>>>>>> Not to forget that Slang itself relies heavily on C, which is only >>>>>>> the core of the VM and the very core of the implementation. >>>>>>> >>>>>>> Understanding how to work with pointers in C is pretty much >>>>>>> understanding how to works with Objects in Smalltalk. Both are nuclear >>>>>>> weapons that those two languages are build around. If ones does not >>>>>>> understand their usage he will shoot his foot in the end. >>>>>>> >>>>>>> The important thing to remember is that C's goal is not the same as >>>>>>> of Smalltalk. Its not there to hold your hand and make coding easy for you. >>>>>>> C is there to offer low level access combined with top performance. It may >>>>>>> have started as a general purpose language decades ago when coding in >>>>>>> Assembly was still a pleasant experience. Nowdays C has completely replaced >>>>>>> Assembly as the top performance language for low level coding. >>>>>>> >>>>>>> C may appear as a problematic language to a Smalltalker but only >>>>>>> because he sees it from the Smalltalk point of view. The harsh reality of >>>>>>> the world is that as much as one may want to shoehorn it , not everything >>>>>>> can be elegantly mapped to a object. Smalltalk may be OO to the bone , but >>>>>>> the world we live in, cannot afford such simple structures to accomodate of >>>>>>> varied immense complexity. >>>>>>> >>>>>>> On the subject of pointers, the general rule of thumb is to keep >>>>>>> things as simple as possible and avoide trying to do weird "magic" with >>>>>>> them. There is a ton of things that C does under the hood to generate >>>>>>> highly optimised machine code that can fry the brain , as the usual case >>>>>>> with low level coding, so keeping it simple is the way to go. >>>>>>> >>>>>>> Oh and dont try to shoehorn the Live coding enviroment in debugging >>>>>>> C code, as much as one may want to brag of Smalltalk's elegant debugger, C >>>>>>> development tools are light years ahead in dealing with C problems. >>>>>>> >>>>>>> May advice to people is that if you do it via FFI first, you do it >>>>>>> wrong. >>>>>>> >>>>>>> Do it always first with C with a powerful C IDE like Visual Studio, >>>>>>> make sure your code works there and then use the UFFI. Will make life >>>>>>> thousand times easier. I learned that the hard way when I was playing >>>>>>> around with Pharo and shared memory. >>>>>>> >>>>>>> So yes having a FFI that does not help you avoid coding in C first, >>>>>>> is a big plus, not a minus. Sometimes it makes sense to live outside the >>>>>>> image, this is an excellent case to prove why that is a great idea. . >>>>>>> >>>>>>> On Mon, Nov 6, 2017 at 11:10 AM Nicolas Cellier < >>>>>>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>>>> >>>>>>>> Hi Ben, >>>>>>>> It's a super bad idea to copy an ExternalAddress. >>>>>>>> It's common knowledge in C++ copy operator & copy constructors... >>>>>>>> >>>>>>>> But it's not obvious to me that you'll have double freeing (unless >>>>>>>> you explicitely free the pointer by yourself). >>>>>>>> If you use gcallocate: then only the original is registered for >>>>>>>> magical auto-deallocation at garbage collection... >>>>>>>> >>>>>>>> What you will have is more somthing like dangling pointer: continue >>>>>>>> to use pointer xa2->a1 when a1 was already freed. >>>>>>>> >>>>>>>> FFI is great, it introduces the problem of C in Smalltalk, >>>>>>>> augmented with the problems of wrapping C in Smalltalk. >>>>>>>> >>>>>>>> >>>>>>>> 2017-11-06 4:23 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>>>>>>> >>>>>>>>> My current employment work hours and roster have severely >>>>>>>>> curtailed the time I have hacking Pharo, so I've not dug enough to be sure >>>>>>>>> of my observations a few months ago, and this is from memory, but I was >>>>>>>>> starting to develop a suspicion about the uniqueness of ExternalAddress(s). >>>>>>>>> >>>>>>>>> A while ago, in order to fix some stability issues on Windows, a >>>>>>>>> guard was added somewhere that slowed down some operations. Looking into >>>>>>>>> this and experimenting with removing the guard I seem to remember VM >>>>>>>>> crashes due to a double-free() of an address, due to there being two >>>>>>>>> ExternalAddresses holding the same external address. >>>>>>>>> >>>>>>>>> My intuition is that that somewhere an ExternalAddress(a1) >>>>>>>>> pointing at a particular external resource address "xa1" was being copied, >>>>>>>>> so we end up with ExternalAddress(a2) also pointing at "xa1", with and >>>>>>>>> object b1 holding a1 and object b2 holding a2. During finalization of b1, >>>>>>>>> ExternalAddress a1 free()d xa1, and a1 was flagged to avoid >>>>>>>>> double-free()ing. But that didn't help when b2 was finalized, since a2 had >>>>>>>>> no indication that xa1 had been free()d. >>>>>>>>> >>>>>>>>> That is... >>>>>>>>> b1-->a1-->xa1 >>>>>>>>> b2 := b1 copy. >>>>>>>>> b2-->a2-->xa1 >>>>>>>>> b1 finalize a1 --> free(xa1) >>>>>>>>> b2 finalize a2 --> free(xa1) --> General Protection Fault >>>>>>>>> >>>>>>>>> It was hard to follow this through and I didn't succeed in >>>>>>>>> tracking down where such a copy might have been made, but the idea >>>>>>>>> simmering in my mind since then is to propose that... >>>>>>>>> >>>>>>>>> ExternalAddresses be unique in the image and behave like >>>>>>>>> Symbols, >>>>>>>>> such that trying to copy one returns the identical object. >>>>>>>>> >>>>>>>>> The idea being that when b2 is finalized, a1 would notice that xa1 >>>>>>>>> had already been free()d and raise a Smalltalk exception rather than a >>>>>>>>> general protection fault. >>>>>>>>> b1-->a1-->xa1 >>>>>>>>> b2 := b1 copy. >>>>>>>>> b2-->a1-->xa1 >>>>>>>>> ^^ >>>>>>>>> b1 finalize a1 --> free(xa1) >>>>>>>>> b2 finalize a1 --> Smalltalk exception >>>>>>>>> >>>>>>>>> >>>>>>>>> I write now in response to Stef since I vaguely remember it being >>>>>>>>> Freetype related. But I also remember the issue being FFI related and >>>>>>>>> Freetype is a plugin not FFI. So I'm not sure my memory is clear and >>>>>>>>> perhaps I have the "wrong end of the stick" but anyway, rather than hold >>>>>>>>> back longer because of that, perhaps this can stimulate some discussion and >>>>>>>>> at least I learn something to clarify my understanding here. >>>>>>>>> >>>>>>>>> cheers -ben >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Oct 28, 2017 at 4:48 PM, Stephane Ducasse < >>>>>>>>> stepharo.self(a)gmail.com> wrote: >>>>>>>>> > >>>>>>>>> > Hi all >>>>>>>>> > >>>>>>>>> > I'm and I guess many of you are fedup about the instability that >>>>>>>>> the >>>>>>>>> > FreeType plugin produces. >>>>>>>>> > >>>>>>>>> > So we need help because clement and esteban are fully booked. >>>>>>>>> > >>>>>>>>> > We have three options: >>>>>>>>> > >>>>>>>>> > - drop Freetype alltogether >>>>>>>>> > - rewrite the plugin >>>>>>>>> > - create a binding using raffaillac sketch >>>>>>>>> > >>>>>>>>> > Now we need help. Who is willing to help us? >>>>>>>>> > Should we try to set up a bounty? >>>>>>>>> > >>>>>>>>> > Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> >

Nov. 8, 2017

Re: [Pharo-dev] LayoutFrame bug

by Nicolas Cellier

I know it's not the recommended way... But if experiencing difficulties with iceberg, you can just use MC to produce the tonel output file, then use any git client to do the commit and the pull request... At worse, you can even modify the tonel file directly without MC (more dangerous) I'm often using sourcetree which is really one of the lowest barrier client to git (both macosx and windows, not linux though). Last time, I did it with git command line, then emmitted the PR from github web API. It's just 4 lines: git branch blablabranch; git src add; git commit; git push --set-upstream origin blablabranch I managed to create the branch from iceberg with fogbugz entry # so it was 3 commands and less blabla for me :) And the last alternative is to correct directly the file thru github web API. It's more boring to create a correct branch name and reference the bug entry etc... but it may work. 2017-11-08 22:29 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi nicolas > > Tx I fixed it before seeing your email. Too bad. > > I introduced this bug when I did the asLayoutFrame conversion. > Note that I split the refactoring in parts to avoid too change commits. > Now I was also thinking how I could automate the change and this is > not that easy because the expressions > can use temps, instance variables... and it would take me age to be > able to write a rewrite expression (sadly enough). > > > I found it in 3 min because I know the changes I did but your way is > quite nice because it was not easy to find from the stack trace. > > I fixed it but I cannot commit the fix. Iceberg does not let me. > Now I cannot produce a PR. :( > > https://pharo.fogbugz.com/f/cases/20656/Nautilus-comment- > panel-got-broken-by-asLayoutFrame-cleans > > Guille told me that I could modify the printOn: method to help me. > And this is a bit better (I did not bother to be smart with ; or not) > I will use this trick to ease the refactoring and minimize errors > (probably sleeping more should help too and doing less boring tasks > too :). > > > printOn: aStream > > aStream nextPutAll: ' (LayoutFrame identity '. > self leftFraction = 0 > ifFalse: [ aStream << ('leftFraction: ', self leftFraction printString, ' > ') ]. > self topFraction = 0 > ifFalse: [ aStream << ('topFraction: ', self topFraction printString, ' ') > ]. > self rightFraction = 1 > ifFalse: [ aStream << ('rightFraction: ', self rightFraction > printString, ' ') ]. > self bottomFraction = 1 > ifFalse: [ aStream << ('bottomFraction: ', self bottomFraction > printString,' ') ]. > self leftOffset = 0 > ifFalse: [ aStream << ('leftOffset: ', self leftOffset printString,' ') ]. > self topOffset = 0 > ifFalse: [ aStream << ('topOffset: ', self topOffset printString,' ') ]. > self rightOffset = 0 > ifFalse: [ aStream << ('rightOffset: ', self rightOffset printString,' ') > ]. > self bottomOffset = 0 > ifFalse: [ aStream << ('bottomOffset: ', self bottomOffset printString,' > ') ]. > aStream nextPutAll: ' ) ' > > > > On Wed, Nov 8, 2017 at 1:58 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Yeah, I just got in trouble too by looking at class comments. > > > > Heroic debugging, Nicolas ! > > > >> On 8 Nov 2017, at 13:47, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > >> > >> Hi, > >> don't you get nice red-cross when opening a browser and selecting > comment? > >> (Pharo7.0-32bit-b5ec533.image) > >> > >> The problem is LayoutFrame having a Point instead of Number in > fraction/offset inst. var. > >> > >> So I defined two horrible hacks in order to be able to work with Pharo > >> > >> Point>>@ n ^x @ n > >> Point>>asInteger ^x asInteger > >> > >> then could instrument the LayoutFrame inst. var. setters with horrible > checks like: > >> aNumber isNumber ifFalse: [ self halt]. > >> > >> And after a few seconds of IDE usage: > >> > >> AbstractNautilusUI>>buildCodePanelWithCommentOnRight > >> ...snip... > >> sourceCodePanel > >> addMorph: commentWidget > >> fullFrame: (LayoutFrame identity leftFraction: 0.5@0 ; > >> leftOffset: delta). > >> > >> Huh! it's as pleasant as not eating own dog food > >> I think this comes from a recent refactoring. I can hardly use in > image tools to trace it. > >> Iceberg bugs, MC has lost ancestry and is just good at synchronizing > disk working copy with image working copy, but there is github & git API: > >> > >> https://github.com/pharo-project/pharo/commit/ > 042baad47fddb63db2dd0beefeec692962f06dfe#diff- > b8c1cff56276a5a583eec641253123da > >> > >> As it's nearly impossible to make giant refactorings like this without > human error, > >> and as it's as impossible to review pull request with many lines of > code, > >> I wonder if it is possible to automate those with rewrite rules... > >> > >> I let you finish the work (open issue, patch, commit, etc...) > >> > >> > > > > > >

Nov. 8, 2017

You can cheat in FFI as long as you don't get caught...

by Nicolas Cellier

I was trying to inquire about my latest vm crash in libgit2 https://pharo.fogbugz.com/f/cases/20655/vm-crash-in-libgit-git_tree_free-th… when I found this bizarre prototype: ^ self callUnchecked: #(LGitReturnCodeEnum git_diff_tree_to_tree #(LGitDiff * diff , LGitRepository repo , LGitTree old_tree , LGitTree new_tree , LGitDiffOptions * opts)) options: #() While the libgit2 signature differs in indirection levels: https://libgit2.github.com/libgit2/#v0.19.0/group/diff/git_diff_tree_to_tree int git_diff_tree_to_tree(git_diff_list **diff, git_repository *repo, git_tree *old_tree, git_tree *new_tree, const git_diff_options *opts); The fact that it does not differs for opts, made me think of a bug... But no. opts is allocated on external c heap with: callUnchecked: #(LGitReturnCodeEnum git_diff_init_options(LGitDiffOptions * self, LGitOptionsVersionsEnum version)) int git_diff_init_options(git_diff_options *opts, unsigned int version); What you see this time is that signatures match... So the LGitDiffOptions handle will be an ExternalAddress that will really point on a git_diff_options In other words, the handle is a git_diff_options *... IOW, our LGitDiffOptions object points to an external it_diff_options so it is what it promises to be. For the other structures not so. We are lying on the level of indirection, so our LGitTree handle are not really a git_tree *. They are a git_tree **. (an ExternalAddress on a pointer). As long as we lie consistently, it's OK, because it avoids too much packToArity: unpackToArity: dance. That's the "beauty" of C pointers. We can cast them to whatever or pretend they are handle_for_anything * in the intermediate level, as long as original producer and final consumer agree on what it really points to. But from code quality perspective, it really stinks. Anyone like me opening a page to get the exact signature of the function will be scratching head and loose precious time. Especially when tracking vm crash down. I'm not sure how well it's documented, I presume it's a well known conscious hack from the original developpers, but such practice really ought to be discussed here.

Nov. 8, 2017

Re: [Pharo-dev] ExternalAddress uniqueness (was Re: Call for help for stability and rewrite of FreeType)

by Ben Coman

Thanks for your deep dive on this Nicolas. I'm not familiar with that part of the system, and its interesting to read about the interface constraints. cheers -ben On Wed, Nov 8, 2017 at 11:40 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-11-08 16:10 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> >> >> 2017-11-08 15:35 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com>: >> >>> >>> >>> 2017-11-08 14:53 GMT+01:00 Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>> >>>> >>>> 2017-11-08 14:42 GMT+01:00 Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com>: >>>> >>>>> >>>>> Ben, >>>>> >>>>> This is my fresh crash.dmp >>>>> it sounds very related to your analysis!!! >>>>> >>>>> In fact we are not freeing by ourselves, but telling libgit2 to do >>>>> it... >>>>> >>>>> >>>> Oh worse than that, it sounds like git implemented its own mechanism of >>>> counted pointers... >>>> So we don't tell anything, he guesses by himself. >>>> I would search for places where we #gcallocate: or manually #free a >>>> pointer on a structure passed back by git... >>>> >>>> >>> and of course, it's not gcallocate: because this was a very old wheel... >>> It's rather somewhere in UFFI equivalent >>> FFIExternalResourceExecutor <- FFIExternalResourceManager <- >>> LGitExternalStructure autoRelease >>> >>> Among the senders, we see (tiens, tiens...): >>> LGitTree>>... >>> >>> So this is where I would search the origin of my own crash dump... >>> >>> But also (tiens, tiens...): >>> CairoFontFace>>initializeWithFreetypeFace: >>> >>> What if FreeType plugin was not the problem per se, but its usage in >>> cairo was? >>> >>> cairo_font_face_destroy () >>> void cairo_font_face_destroy >>> (cairo_font_face_t *font_face); >>> Decreases the reference count on font_face by one. If the result is >>> zero, *then font_face and all associated resources are freed*. See >>> cairo_font_face_reference(). >>> font_face : >>> a cairo_font_face_t >>> >>> Since we pass a pointer to the free type font at creation: >>> >>> fromFreetypeFace: aFace >>> | handle cairoFace | >>> handle := aFace handle pointerAt: 1. >>> cairoFace := self primFtFace: handle loadFlags: ( LoadNoHinting | >>> LoadTargetLCD | LoadNoAutohint | LoadNoBitmap). >>> ^ cairoFace initializeWithFreetypeFace: aFace >>> >>> Isn't it possible that we somehow double free the free type font too? >>> >>> >> Hmm not the exact catch but it could well be related >> >> https://www.cairographics.org/manual/cairo-FreeType-Fonts.html tells how >> to couple lifetime of the 2 data structures. >> I see that CairoFontFace retains a pointer on the FT_Face thru a >> dedicated ivar, so at least, we don't free the FT_Face twice, and we don't >> free it until we free the cairo_ft_face >> >> When finalizatoin occurs, I'm not sure that the finalization order is >> guaranteed but that does not matter. >> What matters is that the cairo_ft_face could still be referenced >> internally by cairo. >> >> So what can happen is that: >> 1) we don't reference anymore the CairoFontFace from within Smalltalk >> 2) finalization happens we call cairo_font_face_destroy () >> 3) there is no more pointer on the FTFace from within Smalltalk (because >> we just reclaimed the CairoFontFace pointing on it) >> 4) finalization happens and we call FT_Done_Face() >> >> BUT: cairo was still using the cairo_font_face internally, (the reference >> count did not reach zero) and is now pointing on freed memory due to >> FT_Done_Face()... >> >> We should have tested the status before invoking FT_Done(): >> >> status = cairo_font_face_set_user_data (font_face, &key, >> ft_face, (cairo_destroy_func_t) FT_Done_Face); >> >> That means that we would have to performa that status test in the >> finalization, and if not ready, keep a reference to both cairo_font_face >> handle ft_face handle >> But then there is no other mean than storing those reference in a safe >> place and regularly poll for readiness >> If my understanding is correct, this is absolutely garbage collector >> unfriendly! >> >> > No total misunderstanding from my side... > by setting the user data and destroy function, we are asking to > auto-release the ft_face > In which case, it's bad, because the ft_face is not ref-counted and we > might still have another pointer on it from within Smalltalk > > The only way is thus to poll thru: > > cairo_font_face_get_reference_count (*cairo_font_face_t <https://www.cairographics.org/manual/cairo-cairo-font-face-t.html#cairo-fon…> *font_face*); > > If the count is 1, we can safely proceed with finalization. > Else, there is still an internal reference somewhere in cairo and bang! > > I'd suggest to instrument the code with this function: > > CairoFontFace class>>countReferences: handle > " > unsigned int cairo_font_face_get_reference_count > (cairo_font_face_t *font_face); > " > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode> > ^ self nbCall: #( unsigned int cairo_font_face_get_reference_count > (size_t handle)) > > > CairoFontFace class>>reallyFinalizeResourceData: handle > " > void cairo_font_face_destroy > (cairo_font_face_t *font_face); > " > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode> > ^ self nbCall: #( void cairo_font_face_destroy (size_t handle)) > > CairoFontFace class>>finalizeResourceData: handle > (self countReferences: handle) = 1 ifFalse: [self halt: 'Houston, we > gonna have a pointer reference problem']. > ^self reallyFinalizeResourceData: handle > > If suspicion is confirmed, then we'll have to install the ref_count > polling mechanism... > > > >>> >>>>> Stack backtrace: >>>>> [7791E43E] RtlInitializeGenericTable + 0x196 in ntdll.dll >>>>> [7791E0A3] RtlGetCompressionWorkSpaceSize + 0x7e in ntdll.dll >>>>> [751F98CD] free + 0x39 in msvcrt.dll >>>>> [6CD60D43] git_tree_cache_write + 0x2ac in libgit2.dll >>>>> [6CD62073] git_tree__free + 0x53 in libgit2.dll >>>>> [6CD1A563] git_object__free + 0x52 in libgit2.dll >>>>> [6CCD0D78] git_cached_obj_decref + 0x4c in libgit2.dll >>>>> [6CD1A7D9] git_object_free + 0x17 in libgit2.dll >>>>> [6CD1B0D3] git_tree_free + 0x11 in libgit2.dll >>>>> [6CD0BE4F] git_iterator_for_nothing + 0x8aa in libgit2.dll >>>>> [6CD0C053] git_iterator_for_nothing + 0xaae in libgit2.dll >>>>> [6CCEADEF] git_diff_file_content__clear + 0x31d in libgit2.dll >>>>> [6CCECC3F] git_diff__oid_for_entry + 0xc29 in libgit2.dll >>>>> [6CCED2B2] git_diff__oid_for_entry + 0x129c in libgit2.dll >>>>> [6CCED495] git_diff__from_iterators + 0x1db in libgit2.dll >>>>> [6CCED6DE] git_diff_tree_to_tree + 0x1e3 in libgit2.dll >>>>> [004DE7C8] ??? + 0xde7c8 in Pharo.exe >>>>> [0044FE08] ??? + 0x4fe08 in Pharo.exe >>>>> [004516A7] ??? + 0x516a7 in Pharo.exe >>>>> [00446051] ??? + 0x46051 in Pharo.exe >>>>> [0049936E] ??? + 0x9936e in Pharo.exe >>>>> >>>>> >>>>> Smalltalk stack dump: >>>>> 0xafa86c I LGitDiff>diff_tree_to_tree:repo:old_tree:new_tree:opts: >>>>> 0xe585410: a(n) LGitDiff >>>>> 0xafa8a4 M [] in LGitDiff>diffTree:toTree:options: 0xe585410: a(n) >>>>> LGitDiff >>>>> 0xafa8bc M LGitDiff(LGitExternalObject)>withReturnHandlerDo: >>>>> 0xe585410: a(n) LGitDiff >>>>> 0xafc678 I LGitDiff>diffTree:toTree:options: 0xe585410: a(n) >>>>> LGitDiff >>>>> 0xafc6a4 I LGitDiff>diffTree:toTree: 0xe585410: a(n) LGitDiff >>>>> 0xafc6d0 I LGitTree>diffTo: 0xe583e00: a(n) LGitTree >>>>> 0xafc6fc M [] in IceLibgitLocalRepository>changedFilesBetween:and: >>>>> 0x1055afc0: a(n) IceLibgitLocalRepository >>>>> 0xafc720 M [] in IceLibgitLocalRepository>withRepoDo: 0x1055afc0: >>>>> a(n) IceLibgitLocalRepository >>>>> 0xafc73c M [] in LGitGlobal class>runSequence: 0xfb96188: a(n) >>>>> LGitGlobal class >>>>> 0xafc760 M [] in LGitActionSequence(DynamicVariable)>value:during: >>>>> 0x102109f8: a(n) LGitActionSequence >>>>> 0xafc780 M BlockClosure>ensure: 0xe582890: a(n) BlockClosure >>>>> 0xafc7ac I LGitActionSequence(DynamicVariable)>value:during: >>>>> 0x102109f8: a(n) LGitActionSequence >>>>> 0xafc7cc M LGitActionSequence class(DynamicVariable >>>>> class)>value:during: 0xfbb81e0: a(n) LGitActionSequence class >>>>> 0xafc7f4 I LGitGlobal class>runSequence: 0xfb96188: a(n) LGitGlobal >>>>> class >>>>> 0xafc818 I IceLibgitLocalRepository>withRepoDo: 0x1055afc0: a(n) >>>>> IceLibgitLocalRepository >>>>> 0xafc840 I IceLibgitLocalRepository>changedFilesBetween:and: >>>>> 0x1055afc0: a(n) IceLibgitLocalRepository >>>>> 0xafc874 I IceCommitInfo>changedPackagesToCommitInfo: 0x113b80e0: >>>>> a(n) IceCommitInfo >>>>> 0xafc898 I IceCommitInfo>changedPackagesTo: 0x113b80e0: a(n) >>>>> IceCommitInfo >>>>> 0xafc8c0 I IceDiff>initialElements 0xe4c48f8: a(n) IceDiff >>>>> 0xaf9664 I IceDiff(IceAbstractDiff)>elements 0xe4c48f8: a(n) IceDiff >>>>> 0xaf9684 I IceDiffChangeTreeBuilder>elements 0xe4b9c80: a(n) >>>>> IceDiffChangeTreeBuilder >>>>> 0xaf969c M [] in IceDiffChangeTreeBuilder>buildOn: 0xe4b9c80: a(n) >>>>> IceDiffChangeTreeBuilder >>>>> >>>>> Dimitris: >>>>> >>>>> I won't argument, I've learnt C in 1987, so it gave me enough time to >>>>> learn my own limits. >>>>> Working with pointers is like carrying a gun without engaging the >>>>> safety catch. >>>>> I came to think that shooting own foot was a feature ;) >>>>> >>>>> 2017-11-06 11:04 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >>>>> >>>>>> Its the usual case of not being able to have your cake and eat it too. >>>>>> >>>>>> If you want top performance you have to manage memory yourself plus >>>>>> the abilitiy to access thousands of C libraries is not such a bad excuse >>>>>> for a compromise. The FFI is not a problem is a solution to many problems >>>>>> and people using it its not as if Smalltalk offers them any alternative >>>>>> choice. >>>>>> >>>>>> Not to forget that Slang itself relies heavily on C, which is only >>>>>> the core of the VM and the very core of the implementation. >>>>>> >>>>>> Understanding how to work with pointers in C is pretty much >>>>>> understanding how to works with Objects in Smalltalk. Both are nuclear >>>>>> weapons that those two languages are build around. If ones does not >>>>>> understand their usage he will shoot his foot in the end. >>>>>> >>>>>> The important thing to remember is that C's goal is not the same as >>>>>> of Smalltalk. Its not there to hold your hand and make coding easy for you. >>>>>> C is there to offer low level access combined with top performance. It may >>>>>> have started as a general purpose language decades ago when coding in >>>>>> Assembly was still a pleasant experience. Nowdays C has completely replaced >>>>>> Assembly as the top performance language for low level coding. >>>>>> >>>>>> C may appear as a problematic language to a Smalltalker but only >>>>>> because he sees it from the Smalltalk point of view. The harsh reality of >>>>>> the world is that as much as one may want to shoehorn it , not everything >>>>>> can be elegantly mapped to a object. Smalltalk may be OO to the bone , but >>>>>> the world we live in, cannot afford such simple structures to accomodate of >>>>>> varied immense complexity. >>>>>> >>>>>> On the subject of pointers, the general rule of thumb is to keep >>>>>> things as simple as possible and avoide trying to do weird "magic" with >>>>>> them. There is a ton of things that C does under the hood to generate >>>>>> highly optimised machine code that can fry the brain , as the usual case >>>>>> with low level coding, so keeping it simple is the way to go. >>>>>> >>>>>> Oh and dont try to shoehorn the Live coding enviroment in debugging C >>>>>> code, as much as one may want to brag of Smalltalk's elegant debugger, C >>>>>> development tools are light years ahead in dealing with C problems. >>>>>> >>>>>> May advice to people is that if you do it via FFI first, you do it >>>>>> wrong. >>>>>> >>>>>> Do it always first with C with a powerful C IDE like Visual Studio, >>>>>> make sure your code works there and then use the UFFI. Will make life >>>>>> thousand times easier. I learned that the hard way when I was playing >>>>>> around with Pharo and shared memory. >>>>>> >>>>>> So yes having a FFI that does not help you avoid coding in C first, >>>>>> is a big plus, not a minus. Sometimes it makes sense to live outside the >>>>>> image, this is an excellent case to prove why that is a great idea. . >>>>>> >>>>>> On Mon, Nov 6, 2017 at 11:10 AM Nicolas Cellier < >>>>>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>>> >>>>>>> Hi Ben, >>>>>>> It's a super bad idea to copy an ExternalAddress. >>>>>>> It's common knowledge in C++ copy operator & copy constructors... >>>>>>> >>>>>>> But it's not obvious to me that you'll have double freeing (unless >>>>>>> you explicitely free the pointer by yourself). >>>>>>> If you use gcallocate: then only the original is registered for >>>>>>> magical auto-deallocation at garbage collection... >>>>>>> >>>>>>> What you will have is more somthing like dangling pointer: continue >>>>>>> to use pointer xa2->a1 when a1 was already freed. >>>>>>> >>>>>>> FFI is great, it introduces the problem of C in Smalltalk, augmented >>>>>>> with the problems of wrapping C in Smalltalk. >>>>>>> >>>>>>> >>>>>>> 2017-11-06 4:23 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>>>>>> >>>>>>>> My current employment work hours and roster have severely curtailed >>>>>>>> the time I have hacking Pharo, so I've not dug enough to be sure of my >>>>>>>> observations a few months ago, and this is from memory, but I was starting >>>>>>>> to develop a suspicion about the uniqueness of ExternalAddress(s). >>>>>>>> >>>>>>>> A while ago, in order to fix some stability issues on Windows, a >>>>>>>> guard was added somewhere that slowed down some operations. Looking into >>>>>>>> this and experimenting with removing the guard I seem to remember VM >>>>>>>> crashes due to a double-free() of an address, due to there being two >>>>>>>> ExternalAddresses holding the same external address. >>>>>>>> >>>>>>>> My intuition is that that somewhere an ExternalAddress(a1) pointing >>>>>>>> at a particular external resource address "xa1" was being copied, so we end >>>>>>>> up with ExternalAddress(a2) also pointing at "xa1", with and object b1 >>>>>>>> holding a1 and object b2 holding a2. During finalization of b1, >>>>>>>> ExternalAddress a1 free()d xa1, and a1 was flagged to avoid >>>>>>>> double-free()ing. But that didn't help when b2 was finalized, since a2 had >>>>>>>> no indication that xa1 had been free()d. >>>>>>>> >>>>>>>> That is... >>>>>>>> b1-->a1-->xa1 >>>>>>>> b2 := b1 copy. >>>>>>>> b2-->a2-->xa1 >>>>>>>> b1 finalize a1 --> free(xa1) >>>>>>>> b2 finalize a2 --> free(xa1) --> General Protection Fault >>>>>>>> >>>>>>>> It was hard to follow this through and I didn't succeed in tracking >>>>>>>> down where such a copy might have been made, but the idea simmering in my >>>>>>>> mind since then is to propose that... >>>>>>>> >>>>>>>> ExternalAddresses be unique in the image and behave like >>>>>>>> Symbols, >>>>>>>> such that trying to copy one returns the identical object. >>>>>>>> >>>>>>>> The idea being that when b2 is finalized, a1 would notice that xa1 >>>>>>>> had already been free()d and raise a Smalltalk exception rather than a >>>>>>>> general protection fault. >>>>>>>> b1-->a1-->xa1 >>>>>>>> b2 := b1 copy. >>>>>>>> b2-->a1-->xa1 >>>>>>>> ^^ >>>>>>>> b1 finalize a1 --> free(xa1) >>>>>>>> b2 finalize a1 --> Smalltalk exception >>>>>>>> >>>>>>>> >>>>>>>> I write now in response to Stef since I vaguely remember it being >>>>>>>> Freetype related. But I also remember the issue being FFI related and >>>>>>>> Freetype is a plugin not FFI. So I'm not sure my memory is clear and >>>>>>>> perhaps I have the "wrong end of the stick" but anyway, rather than hold >>>>>>>> back longer because of that, perhaps this can stimulate some discussion and >>>>>>>> at least I learn something to clarify my understanding here. >>>>>>>> >>>>>>>> cheers -ben >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Oct 28, 2017 at 4:48 PM, Stephane Ducasse < >>>>>>>> stepharo.self(a)gmail.com> wrote: >>>>>>>> > >>>>>>>> > Hi all >>>>>>>> > >>>>>>>> > I'm and I guess many of you are fedup about the instability that >>>>>>>> the >>>>>>>> > FreeType plugin produces. >>>>>>>> > >>>>>>>> > So we need help because clement and esteban are fully booked. >>>>>>>> > >>>>>>>> > We have three options: >>>>>>>> > >>>>>>>> > - drop Freetype alltogether >>>>>>>> > - rewrite the plugin >>>>>>>> > - create a binding using raffaillac sketch >>>>>>>> > >>>>>>>> > Now we need help. Who is willing to help us? >>>>>>>> > Should we try to set up a bounty? >>>>>>>> > >>>>>>>> > Stef >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> >

Nov. 8, 2017

Re: [Pharo-dev] [Pharo7.0a] Next batch of enhancements

by Stephane Ducasse

Yes this would be good. I should do it and learn how to send an email. Stef On Sun, Nov 5, 2017 at 11:58 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Thanks stef :) > > Question: would you like that we set-up a jenkins job that sends this > report every saturday or monday morning? > > On Sun, Nov 5, 2017 at 10:07 AM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Report period: 23 October 2017 to 5 November 2017 >> >> * 20632-Rename-PluggableSortFunction-to-CollatorBlockFunction >> >> PluggableSortFunction is renamed to CollatorBlockFunction >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20632 >> PR URL: https://github.com/pharo-project/pharo/pull/430 >> Diff URL: https://github.com/pharo-project/pharo/pull/430/files >> >> Thanks to dionisiydk >> >> * 20634 missing super messages in set up and tear down in kernel >> tests unit tests >> >> Add missing super messages in #setUp and #tearDown in Kernel-Tests >> >> >> >> https://pharo.fogbugz.com/f/cases/20634/Missing-super-messag >> es-in-setUp-and-tearDown-in-Kernel-Tests-unit-tests >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20634 missing super >> messages in set up and tear down in kernel tests unit tests >> PR URL: https://github.com/pharo-project/pharo/pull/432 >> Diff URL: https://github.com/pharo-project/pharo/pull/432/files >> >> Thanks to astares >> >> * 20623-Tests-in-the-CI-should-say-the-Architecture-and-the-OS >> >> Adding the node name if running in JENKINS. >> >> >> >> It fixes >> >> >> >> https://pharo.fogbugz.com/f/cases/20623/Tests-in-the-CI-shou >> ld-say-the-Architecture-and-the-OS >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20623 >> PR URL: https://github.com/pharo-project/pharo/pull/424 >> Diff URL: https://github.com/pharo-project/pharo/pull/424/files >> >> Thanks to tesonep >> >> * 20633-Update-Tonel-version >> >> Upgrading Tonel version to 1.0.3. >> >> >> >> Fixes issue https://pharo.fogbugz.com/f/ca >> ses/20633/Update-Tonel-version >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20633 >> PR URL: https://github.com/pharo-project/pharo/pull/431 >> Diff URL: https://github.com/pharo-project/pharo/pull/431/files >> >> Thanks to tesonep >> >> * 20629-wrong-FuelPlatform-Pharo-Core-package-loading >> >> https://pharo.fogbugz.com/f/cases/20629/wrong-FuelPlatform- >> Pharo-Core-package-loading >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20629 >> PR URL: https://github.com/pharo-project/pharo/pull/429 >> Diff URL: https://github.com/pharo-project/pharo/pull/429/files >> >> Thanks to pavel-krivanek >> >> * 20630-The-package-Files-Prompt-is-not-loaded >> >> https://pharo.fogbugz.com/f/cases/20630/The-package-Files-Pr >> ompt-is-not-loaded >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20630 >> PR URL: https://github.com/pharo-project/pharo/pull/427 >> Diff URL: https://github.com/pharo-project/pharo/pull/427/files >> >> Thanks to pavel-krivanek >> >> * 20628-Categories-definition-in-exported-Tonel-must-be-symbol >> s-not-strings >> >> https://pharo.fogbugz.com/f/cases/20628/Categories-definitio >> n-in-exported-Tonel-must-be-symbols-not-strings >> >> >> >> - Converts category names from strings to symbols >> >> - Remove unused packages >> >> >> >> ``` >> >> delete mode 100644 src/BaselineOfHermes/BaselineO >> fHermes.class.st >> >> delete mode 100644 src/BaselineOfHermes/package.st >> >> delete mode 100644 src/Files-Prompt/DummyUIManager.extension.st >> >> delete mode 100644 >> src/Files-Prompt/FileAlreadyExistsException.extension.st >> >> delete mode 100644 >> src/Files-Prompt/FileDoesNotExistException.extension.st >> >> delete mode 100644 src/Files-Prompt/MorphicUIMana >> ger.extension.st >> >> delete mode 100644 >> src/Files-Prompt/NonInteractiveUIManager.extension.st >> >> delete mode 100644 src/Files-Prompt/UIManager.extension.st >> >> delete mode 100644 src/Files-Prompt/package.st >> >> delete mode 100644 src/FuelPlatform-Pharo-Core/FL >> PharoPlatform.class.st >> >> delete mode 100644 src/FuelPlatform-Pharo-Core/package.st >> >> delete mode 100644 src/Hermes-Ring/FiBitsLayout.extension.st >> >> delete mode 100644 src/Hermes-Ring/FiCompiledMeth >> odLayout.extension.st >> >> delete mode 100644 src/Hermes-Ring/FiEphemeronLay >> out.extension.st >> >> delete mode 100644 src/Hermes-Ring/FiFixedLayout.extension.st >> >> delete mode 100644 src/Hermes-Ring/FiImmediateLay >> out.extension.st >> >> delete mode 100644 src/Hermes-Ring/FiLayout.extension.st >> >> delete mode 100644 src/Hermes-Ring/FiPointerLayout.extension.st >> >> delete mode 100644 src/Hermes-Ring/FiVariableLayout.extension.st >> >> delete mode 100644 src/Hermes-Ring/FiWeakVariable >> Layout.extension.st >> >> delete mode 100644 src/Hermes-Ring/HERingBinder.class.st >> >> delete mode 100644 src/Hermes-Ring/HERingToHermes >> Builder.class.st >> >> delete mode 100644 src/Hermes-Ring/RFiClass.extension.st >> >> delete mode 100644 src/Hermes-Ring/RFiEnvironment.extension.st >> >> delete mode 100644 src/Hermes-Ring/RFiMethod.extension.st >> >> delete mode 100644 src/Hermes-Ring/RFiTrait.extension.st >> >> delete mode 100644 src/Hermes-Ring/package.st >> >> delete mode 100644 >> src/Hermes-Tests-External-Package/AClassToBeExtracted.class.st >> >> delete mode 100644 >> src/Hermes-Tests-External-Package/AClassToBeExtractedFactory.class.st >> >> delete mode 100644 >> src/Hermes-Tests-External-Package/HETeSimpleClassWithComplex >> Traits.extension.st >> >> delete mode 100644 >> src/Hermes-Tests-External-Package/TSimpleTraitToBeExtracted.trait.st >> >> delete mode 100644 src/Hermes-Tests-External-Package/package.st >> >> delete mode 100644 >> src/Hermes-Tests/HEAbstractBinaryClassBuilderTest.class.st >> >> delete mode 100644 src/Hermes-Tests/HEExportedLit >> eralTest.class.st >> >> delete mode 100644 src/Hermes-Tests/HEExportingCl >> assTest.class.st >> >> delete mode 100644 src/Hermes-Tests/HEExportingMe >> thodTest.class.st >> >> delete mode 100644 >> src/Hermes-Tests/HEExportingPackageFromRingTest.class.st >> >> delete mode 100644 src/Hermes-Tests/HEExportingPa >> ckageTest.class.st >> >> delete mode 100644 src/Hermes-Tests/HEExportingTr >> aitTest.class.st >> >> delete mode 100644 src/Hermes-Tests/HEInstallWhol >> ePackageTest.class.st >> >> delete mode 100644 src/Hermes-Tests/HEInstallerTest.class.st >> >> delete mode 100644 src/Hermes-Tests/HETeSimpleClass.class.st >> >> delete mode 100644 >> src/Hermes-Tests/HETeSimpleClassWithComplexTraits.class.st >> >> delete mode 100644 src/Hermes-Tests/HETeSimpleCla >> ssWithTraits.class.st >> >> delete mode 100644 src/Hermes-Tests/THEATraitUsin >> gOthers.trait.st >> >> delete mode 100644 src/Hermes-Tests/THEOneTestTrait.trait.st >> >> delete mode 100644 src/Hermes-Tests/THEOtherTestTrait.trait.st >> >> delete mode 100644 src/Hermes-Tests/package.st >> >> delete mode 100644 src/Network-Url/package.st >> >> delete mode 100644 src/Ring-Navigation/RGMethodDe >> finition.extension.st >> >> delete mode 100644 src/Ring-Navigation/package.st >> >> ``` >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20628 >> PR URL: https://github.com/pharo-project/pharo/pull/426 >> Diff URL: https://github.com/pharo-project/pharo/pull/426/files >> >> Thanks to pavel-krivanek >> >> * 20626-Fixing-Tests-in-CI >> >> Fixing some tests related with the refactoring in FileStream. >> >> >> >> Fixes issue >> >> >> >> https://pharo.fogbugz.com/f/cases/20626/Fixing-Tests-in-CI >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20626 >> PR URL: https://github.com/pharo-project/pharo/pull/425 >> Diff URL: https://github.com/pharo-project/pharo/pull/425/files >> >> Thanks to tesonep >> >> * 20616-Convert-file-format-to-tonel >> >> sources converted. >> >> >> >> closes case 20616 >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20616 >> PR URL: https://github.com/pharo-project/pharo/pull/423 >> Diff URL: https://github.com/pharo-project/pharo/pull/423/files >> >> Thanks to estebanlm >> >> * 20574-FFITypeArray--annonymousClassCreator-doesnt-handle- >> pointer-types-correctly >> >> fix case #20574 >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20574 >> PR URL: https://github.com/pharo-project/pharo/pull/392 >> Diff URL: https://github.com/pharo-project/pharo/pull/392/files >> >> Thanks to estebanlm >> >> * 20589-update-iceberg-to-062 >> >> closes case #20589 >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20589 >> PR URL: https://github.com/pharo-project/pharo/pull/397 >> Diff URL: https://github.com/pharo-project/pharo/pull/397/files >> >> Thanks to estebanlm >> >> * 17299 sleep longer than a second in the delay scheduler >> >> Issue URL: https://pharo.fogbugz.com/f/cases/17299 sleep longer >> than a second in the delay scheduler >> PR URL: https://github.com/pharo-project/pharo/pull/197 >> Diff URL: https://github.com/pharo-project/pharo/pull/197/files >> >> Thanks to zecke >> >> * 20599 make kernel independent of deprecated file stream >> >> This PR introduces the following changes: >> >> - Extracted file creation for st and cs files into CodeExporter >> class >> >> - removed usages of StandardFileStream and MultiByteFileStream >> >> - Modularised StandardFileStream>>defaultAction to be in a >> separate package (depends on UI) >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20599 make kernel >> independent of deprecated file stream >> PR URL: https://github.com/pharo-project/pharo/pull/415 >> Diff URL: https://github.com/pharo-project/pharo/pull/415/files >> >> Thanks to guillep >> >> * 20155-Browse-implementers-of-in-Nautilus-doesnt-parse-source >> -code-properly-for-methods-in-a-block >> >> Fixes 20155 using a modificaton of teh code in the Bug report. >> The second commit removes what appears to be dead code; if this one >> casues trouble, it oculd be dropped. (Since the removed methods send >> unimplemented messages, they are unlikely to help!) >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20155 >> PR URL: https://github.com/pharo-project/pharo/pull/410 >> Diff URL: https://github.com/pharo-project/pharo/pull/410/files >> >> Thanks to apblack >> >> * 20609-defaultBackgroundColor-should-be-removed-from-Object >> >> move defaultBackgroundColor from Object to Morph >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20609 >> PR URL: https://github.com/pharo-project/pharo/pull/414 >> Diff URL: https://github.com/pharo-project/pharo/pull/414/files >> >> Thanks to dionisiydk >> >> * 20577-Cleanup-Object-inspection-protocol >> >> replace #explore users with #inspect. >> >> move inspectorClass and Object>>inspector into Spec-Inspector >> >> Object>>explore is deprecated >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20577 >> PR URL: https://github.com/pharo-project/pharo/pull/413 >> Diff URL: https://github.com/pharo-project/pharo/pull/413/files >> >> Thanks to dionisiydk >> >> * 18391-Debugger must guard against actions on process termination >> >> added guards so the debugger doesn't send stepping messages to >> nil contexts. (This was the cause of the freezing because it would >> loop until the context was dead). >> >> >> >> Now the debugger closes when we are stepping out of a >> 'terminal' context instead of showing a 'nil doesNotUnderstand: >> isDead' exception. (It notifiies the user through an inform that the >> debugging session is finished) >> >> Issue URL: https://pharo.fogbugz.com/f/cases/18391 >> PR URL: https://github.com/pharo-project/pharo/pull/409 >> Diff URL: https://github.com/pharo-project/pharo/pull/409/files >> >> Thanks to Marmat21 >> >> * 20576-add-simplified-DADependenciesHTMLPublisher >> >> https://pharo.fogbugz.com/f/cases/20576/add-simplified-DADep >> endenciesHTMLPublisher >> >> >> >> add DADependenciesHTMLPublisher from >> Tool-DependencyAnalyser-HTMLReport-ChristopheDemarey.1.mcz >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20576 >> PR URL: https://github.com/pharo-project/pharo/pull/388 >> Diff URL: https://github.com/pharo-project/pharo/pull/388/files >> >> Thanks to pavel-krivanek >> >> * 20547-missing-assertidenticalTo-and-denyidenticalTo-object-i >> dentity-equality >> >> https://pharo.fogbugz.com/f/cases/20547/missing-assert-ident >> icalTo-and-deny-identicalTo-object-identity-equality >> >> >> >> add assert:identicalTo: and deny:identicalTo: >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20547 >> PR URL: https://github.com/pharo-project/pharo/pull/368 >> Diff URL: https://github.com/pharo-project/pharo/pull/368/files >> >> Thanks to pavel-krivanek >> >> * 20604-Metacello-Platform-is-dependent-on-Metacello-Bitbucket >> >> https://pharo.fogbugz.com/f/cases/20604/Metacello-Platform- >> is-dependent-on-Metacello-Bitbucket >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20604 >> PR URL: https://github.com/pharo-project/pharo/pull/406 >> Diff URL: https://github.com/pharo-project/pharo/pull/406/files >> >> Thanks to pavel-krivanek >> >> * 20615-add-packages-for-MetacelloCommandLineHander-into-baselines >> >> https://pharo.fogbugz.com/f/cases/20615/add-packages-for-Met >> acelloCommandLineHander-into-baselines >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20615 >> PR URL: https://github.com/pharo-project/pharo/pull/421 >> Diff URL: https://github.com/pharo-project/pharo/pull/421/files >> >> Thanks to pavel-krivanek >> >> * 20581-Manually-resolved-dependencies-in-manifests-need-update >> >> https://pharo.fogbugz.com/f/cases/20581/Manually-resolved-de >> pendencies-in-manifests-need-update >> >> >> >> update manually resolved dependencies >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20581 >> PR URL: https://github.com/pharo-project/pharo/pull/391 >> Diff URL: https://github.com/pharo-project/pharo/pull/391/files >> >> Thanks to pavel-krivanek >> >> * 12160-Should-we-move-asUrl-to-Zinc-package >> >> https://pharo.fogbugz.com/f/cases/12160/Should-we-move-asUrl >> -to-Zinc-package >> >> Issue URL: https://pharo.fogbugz.com/f/cases/12160 >> PR URL: https://github.com/pharo-project/pharo/pull/418 >> Diff URL: https://github.com/pharo-project/pharo/pull/418/files >> >> Thanks to pavel-krivanek >> >> * 20584-SortFunction-should-not-use-block-in-collator >> >> SortFunction is now abstract. It is refactored and splitted on >> two extra subclasses: >> >> SortByPropertyFunction to collate objects using property >> defined by selector or one arg block. >> >> PluggableSortFunction represents collator using two args block. >> >> >> >> >> >> So subclasses implement single method #threeWayCompare:with: >> where they define own collarion logic independently from specified >> direction. >> >> Old method #collate:with is now main method which taks into >> account three way comparison and direction. Subclasses do not supposed >> to redefine it. >> >> And #value:value: method just convert collation result into >> the bool (returns is it negative or not). >> >> All functions implements #= and #hash methods. So selector >> based functions can be used in application caches. >> >> Also now applications are able to implement own sort functions >> instead of using selectors or blocks which improves reusability. >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20584 >> PR URL: https://github.com/pharo-project/pharo/pull/412 >> Diff URL: https://github.com/pharo-project/pharo/pull/412/files >> >> Thanks to dionisiydk >> >> * 20602 file locator local directory should be inside image directory >> >> UserLocalDirectory should be placed in imageDirectory by default. >> >> >> >> https://pharo.fogbugz.com/f/cases/20602/FileLocator-localDir >> ectory-should-be-inside-image-directory >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20602 file locator >> local directory should be inside image directory >> PR URL: https://github.com/pharo-project/pharo/pull/419 >> Diff URL: https://github.com/pharo-project/pharo/pull/419/files >> >> Thanks to dionisiydk >> >> * 20613-Improve-some-UUID-comments >> >> Improve some UUID comments >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20613 >> PR URL: https://github.com/pharo-project/pharo/pull/420 >> Diff URL: https://github.com/pharo-project/pharo/pull/420/files >> >> Thanks to svenvc >> >> * 20598 update configuration command line handler to use metacello >> >> A first implementation of a CommandLineHandler for Metacello. >> >> >> >> It provides the ability to install projects using >> Configuration or Baseline. >> >> >> >> It comes with unit tests. >> >> >> >> After a discussion with @Ducasse , the >> ConfigurationCommandLineHandler was not modified in order to not break >> scripts using it. It should be deprecated once this handler provides >> enough features. >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20598 update >> configuration command line handler to use metacello >> PR URL: https://github.com/pharo-project/pharo/pull/416 >> Diff URL: https://github.com/pharo-project/pharo/pull/416/files >> >> Thanks to juliendelplanque >> >> * 20610-Class-comments-displaying-is-failing- >> >> https://pharo.fogbugz.com/f/cases/20610/Class-comments-displ >> aying-is-failing >> >> >> >> fix RubCommentAnnotationDisplayer>>#fontToUse >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20610 >> PR URL: https://github.com/pharo-project/pharo/pull/417 >> Diff URL: https://github.com/pharo-project/pharo/pull/417/files >> >> Thanks to pavel-krivanek >> >> * 20592-SizeInMemory-is-not-updated-to-handle-32-and-64-bits- >> for-WordLayout >> >> Fixing sizeInMemory to handle properly WordLayout objects. >> >> Also fixing the tests to handle both 32 and 64 bits. >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20592 >> PR URL: https://github.com/pharo-project/pharo/pull/400 >> Diff URL: https://github.com/pharo-project/pharo/pull/400/files >> >> Thanks to tesonep >> >> * 20587-remove-UIThemeWatery >> >> https://pharo.fogbugz.com/f/cases/20587-remove-UIThemeWatery >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20587 >> PR URL: https://github.com/pharo-project/pharo/pull/395 >> Diff URL: https://github.com/pharo-project/pharo/pull/395/files >> >> Thanks to pavel-krivanek >> >> * 20551-Improve-way-how-Spec-presenters-are-linked-with-domain-models >> >> https://pharo.fogbugz.com/f/cases/20551/Improve-way-how-Spec >> -presenters-are-linked-with-domain-models >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20551 >> PR URL: https://github.com/pharo-project/pharo/pull/374 >> Diff URL: https://github.com/pharo-project/pharo/pull/374/files >> >> Thanks to pavel-krivanek >> >> * 20600 rename opal compiler encoder from opal encoder to encoder >> >> This can be tested through a boostrap, or by using this do it >> instead of loading the changes: >> >> OpalEncoder withAllSubclassesDo: [ :sub | sub rename: (sub >> name allButFirst: 4)]. >> >> >> >> This cannot be tested through merge (Changes in the kernel). >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20600 rename opal >> compiler encoder from opal encoder to encoder >> PR URL: https://github.com/pharo-project/pharo/pull/404 >> Diff URL: https://github.com/pharo-project/pharo/pull/404/files >> >> Thanks to clementbera >> >> * 19609-FileReferencebase-should-be-before-last-separator >> >> https://pharo.fogbugz.com/f/cases/19609/FileReference-base- >> should-be-before-last-separator >> >> Issue URL: https://pharo.fogbugz.com/f/cases/19609 >> PR URL: https://github.com/pharo-project/pharo/pull/137 >> Diff URL: https://github.com/pharo-project/pharo/pull/137/files >> >> Thanks to pavel-krivanek >> >> * 19746-WeakValueDictionary-has-counter-intuitive-behavior >> >> https://pharo.fogbugz.com/f/cases/19746/WeakValueDictionary- >> has-counter-intuitive-behavior >> >> Issue URL: https://pharo.fogbugz.com/f/cases/19746 >> PR URL: https://github.com/pharo-project/pharo/pull/140 >> Diff URL: https://github.com/pharo-project/pharo/pull/140/files >> >> Thanks to pavel-krivanek >> >> * 20606-AlienSunitperformTest-is-failing >> >> https://pharo.fogbugz.com/f/cases/20606/AlienSunit-performTe >> st-is-failing >> >> >> >> ignore prefix >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20606 >> PR URL: https://github.com/pharo-project/pharo/pull/408 >> Diff URL: https://github.com/pharo-project/pharo/pull/408/files >> >> Thanks to pavel-krivanek >> >> * 20595-The-Bootstrap-process-should-log-the-command-line-comm >> and-executed >> >> Adding the trace option to the bash scripts >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20595 >> PR URL: https://github.com/pharo-project/pharo/pull/402 >> Diff URL: https://github.com/pharo-project/pharo/pull/402/files >> >> Thanks to tesonep >> >> * 20537 Better class tagging in package ProfStef-Tests-Traits >> >> - add some tags like "Mocks", "Traits" and "Tests" to the >> package "ProfStef-Tests-Traits" >> >> and move the classes into them so we better group them for >> browsing >> >> >> >> https://pharo.fogbugz.com/f/cases/20537/Better-class-tagging >> -in-package-ProfStef-Tests-Traits >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20537 Better class >> tagging in package ProfStef >> PR URL: https://github.com/pharo-project/pharo/pull/359 >> Diff URL: https://github.com/pharo-project/pharo/pull/359/files >> >> Thanks to astares >> >> * 20597 Rename-old-Compiler-encoder-to-LegacyEncoders >> >> â¦ Encoders (aka the OpalEncoders) to be named Encoder, and the >> old compiler encoder nobody use to be called whatever people want (I >> name them legacyEncoder). >> >> >> >> Since EncoderForLongForV3 has never worked, and >> EncoderForSistaV1 is not compliant with the old compiler version >> present in Pharo, I also remove them. >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20597 Rename >> PR URL: https://github.com/pharo-project/pharo/pull/403 >> Diff URL: https://github.com/pharo-project/pharo/pull/403/files >> >> Thanks to clementbera >> >> * 20578-add-BaselineOfMonticello-and-BaselineOfMetacello >> >> https://pharo.fogbugz.com/f/cases/20578/add-BaselineOfMontic >> ello-and-BaselineOfMetacello >> >> >> >> - add package Metacello-PharoExtensions >> >> - move class side utility methods from >> BaselineOfPharoBootstrap there for general use >> >> - add BaselineOfMonticello >> >> - add BaselineOfMetacello >> >> - list them in BaselineOfIDE to have them in the image >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20578 >> PR URL: https://github.com/pharo-project/pharo/pull/389 >> Diff URL: https://github.com/pharo-project/pharo/pull/389/files >> >> Thanks to pavel-krivanek >> >> * 20583-introduce-system-dependencies-test >> >> https://pharo.fogbugz.com/f/cases/20583/introduce-system-dep >> endencies-test >> >> >> >> introduce SystemDependenciesTest >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20583 >> PR URL: https://github.com/pharo-project/pharo/pull/393 >> Diff URL: https://github.com/pharo-project/pharo/pull/393/files >> >> Thanks to pavel-krivanek >> >> * [Bug]: Fix Issue 16136 - DateModel: Handle nil Sanely >> >> I've been using this fix in production for two years, so it >> should be relatively reliable >> >> Issue URL: https://pharo.fogbugz.com/f/cases/[Bug]: Fix Issue 16136 >> PR URL: https://github.com/pharo-project/pharo/pull/394 >> Diff URL: https://github.com/pharo-project/pharo/pull/394/files >> >> Thanks to seandenigris >> >> * 20567-Instance-side-LayoutFramefractions-fractionsOrNil- >> offsets-should-be-deprecated >> >> Fixed all the missing users and deprecate these methods!!! >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20567 >> PR URL: https://github.com/pharo-project/pharo/pull/386 >> Diff URL: https://github.com/pharo-project/pharo/pull/386/files >> >> Thanks to Ducasse >> >> * 20596-Zinc-should-not-use-asBytesDescription-as-it-is-deprecated >> >> Zinc is using #asBytesDescription. It should not be used as it >> is deprecated. >> >> This error is affecting all the users of Zinc. Ex: Smalltalk CI >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20596 >> PR URL: https://github.com/pharo-project/pharo/pull/401 >> Diff URL: https://github.com/pharo-project/pharo/pull/401/files >> >> Thanks to tesonep >> >> * 20026-Diff-has-incorrect-positions-red-and-green-colors-of- >> changed-text >> >> The patch difference should have the cr character. If the >> patch has multiple lines and it does not have the CR, the resulting >> highlight is shifted a character per line. >> >> >> >> Issue: [https://pharo.fogbugz.com/f/c >> ases/resolve/20026/Diff-has-incorrect-positions-red-and-gree >> n-colors-of-changed-text](https://pharo.fogbugz.com/f/cases/ >> resolve/20026/Diff-has-incorrect-positions-red-and-green- >> colors-of-changed-text) >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20026 >> PR URL: https://github.com/pharo-project/pharo/pull/396 >> Diff URL: https://github.com/pharo-project/pharo/pull/396/files >> >> Thanks to tesonep >> >> * 20569-Update-Layout-class-comment >> >> better class comment >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20569 >> PR URL: https://github.com/pharo-project/pharo/pull/385 >> Diff URL: https://github.com/pharo-project/pharo/pull/385/files >> >> Thanks to Ducasse >> >> * 20557-Update-Zinc-and-Zodiac >> >> https://pharo.fogbugz.com/f/cases/20557/Update-Zinc-and-Zodiac >> >> >> >> merge packages: >> >> Zodiac-Tests-SvenVanCaekenberghe.18 >> >> Zinc-Character-Encoding-Core-SvenVanCaekenberghe.54 >> >> Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.35 >> >> Zinc-HTTP-SvenVanCaekenberghe.469 >> >> Zinc-Resource-Meta-Core-SvenVanCaekenberghe.65 >> >> Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.38 >> >> Zinc-Tests-SvenVanCaekenberghe.243 >> >> Zinc-Zodiac-SvenVanCaekenberghe.40 >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20557 >> PR URL: https://github.com/pharo-project/pharo/pull/379 >> Diff URL: https://github.com/pharo-project/pharo/pull/379/files >> >> Thanks to pavel-krivanek >> >> * 20580-ValueChanged-should-be-moved-to-System-Model >> >> https://pharo.fogbugz.com/f/cases/20580/ValueChanged-should- >> be-moved-to-System-Model >> >> >> >> move ValueChanged to the package System-Model >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20580 >> PR URL: https://github.com/pharo-project/pharo/pull/390 >> Diff URL: https://github.com/pharo-project/pharo/pull/390/files >> >> Thanks to pavel-krivanek >> >> * 20575-TextMorph-cannot-work-without-code-completion-temporary-solution >> >> https://pharo.fogbugz.com/f/cases/20575/TextMorph-cannot-wor >> k-without-code-completion-temporary-solution >> >> >> >> safer access to code completion >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20575 >> PR URL: https://github.com/pharo-project/pharo/pull/387 >> Diff URL: https://github.com/pharo-project/pharo/pull/387/files >> >> Thanks to pavel-krivanek >> >> * 20573-BaselineOfMorphic-should-include-System-Identification >> >> https://pharo.fogbugz.com/f/cases/20573/BaselineOfMorphic-sh >> ould-include-System-Identification >> >> >> >> move System-Identification to the BaselineOfMorphic >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20573 >> PR URL: https://github.com/pharo-project/pharo/pull/384 >> Diff URL: https://github.com/pharo-project/pharo/pull/384/files >> >> Thanks to pavel-krivanek >> >> * 20546-There-is-no-denyequals-method-in-TestCase- >> >> https://pharo.fogbugz.com/f/cases/20546 >> >> >> >> - simulate TAssertable flattening >> >> - use different unexpected equality error message >> >> - add denyCollection:equals: >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20546 >> PR URL: https://github.com/pharo-project/pharo/pull/366 >> Diff URL: https://github.com/pharo-project/pharo/pull/366/files >> >> Thanks to pavel-krivanek >> >> * 20560-Fix-instance-veriables-for-Spec-presenters-ending-with--model >> >> https://pharo.fogbugz.com/f/cases/20560/Fix-instance-veriabl >> es-for-Spec-presenters-ending-with-model >> >> >> >> fix some presenters instance veriables with wrong names >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20560 >> PR URL: https://github.com/pharo-project/pharo/pull/381 >> Diff URL: https://github.com/pharo-project/pharo/pull/381/files >> >> Thanks to pavel-krivanek >> >> * 20564-Spec-Core-must-be-Morphic-independent >> >> https://pharo.fogbugz.com/f/cases/20564/Spec-Core-must-be-Mo >> rphic-independent >> >> Issue URL: https://pharo.fogbugz.com/f/cases/20564 >> PR URL: https://github.com/pharo-project/pharo/pull/383 >> Diff URL: https://github.com/pharo-project/pharo/pull/383/files >> >> Thanks to pavel-krivanek >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Nov. 8, 2017