April 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] the new "fixed" compactor VM has FT broken...

by Peter Uhnak

Using the April 03 VM (the "latest" that was on Apr 03). The vm is way more stable (this is the first crash in two active days, which is record for me), so maybe the main cause of the problem has been fixed, but not all causes. I am also downloading latest (Apr 04) VM. There is no crash dump, but it crashed here: Unhandled exception at 0x00409287 in Pharo.exe: 0xC0000005: Access violation reading location 0x00000000. crash context: 00409258 ret 00409259 mov eax,dword ptr ds:[0059CD7Ch] 0040925E test al,3 00409260 jne 0040928B 00409262 mov ecx,dword ptr ds:[59CD40h] 00409268 lea edx,[ecx-1] 0040926B cmp eax,edx 0040926D jb 0040928B 0040926F cmp dword ptr ds:[59CD4Ch],eax 00409275 jb 0040928B 00409277 mov ecx,dword ptr ds:[5BE0D0h] 0040927D cmp dword ptr [eax-4],ecx 00409280 jb 0040928B 00409282 mov eax,dword ptr ds:[0059CD60h] --> 00409287 movzx eax,byte ptr [eax] 0040928A ret registers: EAX=00000000 EBX=00ADC994 ECX=10200000 EDX=00ADD240 ESI=00000000 EDI=00000000 EIP=00409287 ESP=00ADC044 EBP=00ADC964 EFL=00010202 Peter On Mon, Apr 03, 2017 at 03:27:53PM +0200, Peter Uhnak wrote: > Thank you Esteban! > > I've downloaded the latest VM and fonts on cairo now work. I believe this was the last VM crash I am aware of, so hopefully I will have a productive and stable year with Pharo 6. :) > > (I had some issues with dlls not loading on startup sometimes (mentioned in other thread SurfacePlugin.dll)... but this correlates with some other Windows issues...so I need more info myself). > > Thanks! > > Peter > > On Mon, Apr 03, 2017 at 12:12:08PM +0200, Esteban Lorenzano wrote: > > Hi Peter, > > > > I think I fixed the problem, can you try latest vm? > > > > Esteban > > > > > > > On 31 Mar 2017, at 14:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > > > > > Peter I took the latest mac VM and Moose 6.1 and I used your example > > > then I played during 15 min with all the roassal examples and I cannot reproduce > > > but I'm on mac. > > > > > > > > > > > > On Fri, Mar 31, 2017 at 2:23 PM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > > > Tx peter! > > > I really really sorry for this state of affair. > > > I would like to tell you that I thank you for all the feedback you sent. Please continue. > > > I imagine what it is to get a system that blow up under your fingers. > > > I'm always trying to work with the alpha version (because I attract bugs) > > > I got some crashes playing with roassal - but I updated to the latest vm and trying. > > > > > > Can you sync with esteban so that he can access your setup? And yes we are burning > > > esteban on this.... We should pay attention that our faery does not get too exhausted :). > > > > > > Stef > > > > > > > > > On Fri, Mar 31, 2017 at 1:10 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > > > > > > > > > On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > BTWâ¦ I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHESâ¦ and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM. > > > > > > So, all this discussion is informative, but the mail that originates it can be reviewed :) > > > > > > No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's yet another cairo issue? But it complains about FT fonts... > > > > > > I did mention that it crashed on Athens canvas, so e.g. any Roassal presentation that contains text > > > > > > v := RTView new. > > > v add: (RTLabel new elementOn: '-_-'). > > > v > > > > > > <fml.png> > > > â > > > > > > Or running AthensSurfaceExamples class>>exampleDrawText > > > > > > <fml_squared.png> > > > > > > > > > In the past 15 months there was not a single week when the VM would just work without crashing or failing, and seeing that Pharo 6/lastest VM one day before release still doesn't work makes me really question why I still put up with this. > > > > > > Peter > > > > > > > > > > > > Esteban > > > > > > > > >> On 29 Mar 2017, at 14:43, phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: > > >> > > >> We cannot work in 5.0 professionally with the VM released at the time. > > >> I am also using an intermediate VM thing to do the job. > > >> > > >> That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point. > > >> > > >> Phil > > >> > > >> On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > >> > > >> > On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > > >> > > > >> > On Wed, Mar 29, 2017 at 11:05:28AM +0200, Esteban Lorenzano wrote: > > >> >> wellâ¦ > > >> >> > > >> >> Latest VM is intended to work with latest Pharo, not with older versions. > > >> >> Latest VM is *always* an experimental/unstable VM that needs to be consideredâ¦ that, experimental and unstable. Otherwise there would not be point on having the distinction between stable/latest, isnât? > > >> >> > > >> > > > >> >> So, no, Latest VM (which can also be known as âalpha vmâ) has not broken FT, it works fine in Pharo 6.0, which can also be know as âPharo 6.0 Alphaâ). > > >> >> > > >> >> BTWâ¦ Thatâs why in zeroconf you cannot download a âlatest vm for Pharo 5â. > > >> >> > > >> >> Of course, you can live at the edge, but that doesnât means something is broken when something fails if premises are not fulfilled :) > > >> > > > >> > Well considering VM for Pharo 5 never worked for me properly, whether it was crashing on BitBlt/Cairo, FT, or who knows what, I don't really have a choice but to use the latest. If there is a better way then I am all ears, constantly dealing with crashing VM when I need to get work done is extremely frustrating... > > >> > > > >> > Also I was under the impression that newer VM should work with older images, with the only exception being Cog/Spur change. Or should I have six different VMs and Pharo Launcher with six different VM configurations? > > >> > > >> we moved the paradigm a couple of years ago: each Pharo version comes with his own VM version (Other smalltalks do that too). > > >> Being infinite backward compatible is a lot of pain :) > > >> > > >> so yes, PharoLauncher needs to adapt to itâ¦ I added that requirement for PharoLauncher: you ship with latest stable but you can always download newers or olders (this is not yet implemented, is just a requirement I addedâ¦ well, couple of years ago when we changed the way we wanted VMs to work). > > >> > > >> Esteban > > >> > > >> > > > >> > Peter > > >> > > > >> >> > > >> >> Said thatâ¦ I had no problems with Latest VM + Pharo 6.0 (and they may happen, since this is all alfa :P) > > >> >> > > >> >> I donât know if âworkarounding the VMâ (by renaming libfreetype) will work, but if that works, ONCE we move latest vm to stable status we can consider backporting it to Pharo 5. > > >> >> > > >> >> Esteban > > >> >> > > >> >>> On 29 Mar 2017, at 10:37, Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > > >> >>> > > >> >>> The new "fixed" compactor VM has broken FT... > > >> >>> > > >> >>> So any text drawn on Athens canvas results in red cross... > > >> >>> > > >> >>> Error in... > > >> >>> > > >> >>> CairoFontFace class>>primFtFace:loadFlags: > > >> >>> > > >> >>> 'Unable to find function address' > > >> >>> > > >> >>> Apparently because someone renamed libfreetype-6.dll to libfreetype.dll > > >> >>> > > >> >>> (Windows VM latest, Pharo 5) > > >> >>> > > >> >> > > >> >> > > >> > > > >> > > >> > > >> > > > > > > > > > > > > > >

April 5, 2017

[pharo-project/pharo-core]

by GitHub

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

April 5, 2017

[pharo-project/pharo-core] 9138e4: 60460

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 9138e4ac13e0c23ba5b0c1335ff0adec36dec998 https://github.com/pharo-project/pharo-core/commit/9138e4ac13e0c23ba5b0c133… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-04-05 (Wed, 05 Apr 2017) Changed paths: M GT-Playground.package/GTPlayground.class/instance/building/compose.st R Kernel.package/SmallInteger.class/instance/system primitives/instVarAt_.st A OpalCompiler-Core.package/OCAbortCompilation.class/README.md A OpalCompiler-Core.package/OCAbortCompilation.class/class/accessing/sourceCode_.st A OpalCompiler-Core.package/OCAbortCompilation.class/definition.st A OpalCompiler-Core.package/OCAbortCompilation.class/instance/accessing/sourceCode.st A OpalCompiler-Core.package/OCAbortCompilation.class/instance/accessing/sourceCode_.st M OpalCompiler-Core.package/SyntaxErrorNotification.class/class/exceptionInstantiator/inClass_withCode_doitFlag_errorMessage_location_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60459.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60460.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60459.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60460.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools.package/SyntaxErrorDebugger.class/class/instance creation/buildMorphicViewOn_.st A Tools.package/SyntaxErrorDebugger.class/instance/menu/handleWindowClosed.st Log Message: ----------- 60460 18028 Playground play-cache does ignore rename of current working directory https://pharo.fogbugz.com/f/cases/18028 19895 Remove SmallInteger>>#instVarAt: https://pharo.fogbugz.com/f/cases/19895 19855 SyntaxErrorNotification skips ensured block https://pharo.fogbugz.com/f/cases/19855 19916 Fix correct author naming https://pharo.fogbugz.com/f/cases/19916 http://files.pharo.org/image/60/60460.zip

April 5, 2017

Re: [Pharo-dev] ftp repositories broken

by Denis Kudriashov

Hi guys. I could not accept your explanation because I have test which works on latest squeakVM and not works on latest pharoVM. Try filein attachment and check it on both VMs. Test not depends on any difference between squeak and pharo images. You run it on both systems (not only VM's). I found that #primitiveFindSubstring not depends on receiver and you can put it on any class in system (in github C code there is no users of "rcvr" variable). So I just copy primitive method in test class. But I could imaging that I not see/know something trivial. I will be glad to expand my mind :) but I see only reason: primitive is different (or absent) on latest pharoVM. 2017-04-04 19:03 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 4 Apr 2017, at 19:00, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-04-04 18:45 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> > I think you are wrong because I check it carefully in Squeak and I >> found it on github https://github.com/OpenSmallta >> lk/opensmalltalk-vm/search?utf8=â&q=primitiveFindSubstring&type=. >> >> >> still is not there, because is not the same primitive :) >> > > Does it also means that latest VM is built differently then stable? > (primitive works on stable pharo). I just thought that we already moved to > opensmalltalk build process. > > > stable works because the bug ByteString>>#findâ¦ instead of String>>#findâ¦ > was introduced later. > >

April 5, 2017

[pharo-project/pharo-core]

by GitHub

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

April 5, 2017

[pharo-project/pharo-core] 0bb790: 60459

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 0bb790cd74c3d0007c988699cf60e1675a1649a3 https://github.com/pharo-project/pharo-core/commit/0bb790cd74c3d0007c988699… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-04-05 (Wed, 05 Apr 2017) Changed paths: M Epicea.package/EpMonitor.class/instance/private/subscribeToJobAnnouncer.st M OpalCompiler-Core.package/OpalCompiler.class/README.md R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60458.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60459.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60458.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60459.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60459 19907 Improve Comment OpalCompiler https://pharo.fogbugz.com/f/cases/19907 19911 Epicea makes a memory leak https://pharo.fogbugz.com/f/cases/19911 http://files.pharo.org/image/60/60459.zip

April 5, 2017

Re: [Pharo-dev] Missed tech-talk... my apologies

by denker

> On 5 Apr 2017, at 09:17, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > I missed (2nd time) the tech talk of yesterday. > Truth is that Iâm running trying to getting everything ready for release and I completely forget about it :( > > So, I think best is just to skip last monthâs tech-talk (it was already delayed once) and focus in currentâs one (and in releasing). > Yes, sadly I was completely busy and distracted, too (and sadly not even with the Pharo releaseâ¦) The next event is planned for 25 Apr 2017 and has no topic, so I will change it to be about Pharo6 to replace the one missed. https://association.pharo.org/event-2492398 <https://association.pharo.org/event-2492398> (sadly the reason I was busy is not solved and just moved to exactly that week, so I might no be able to a) join b) remember it, same as last week/this week). Marcus

April 5, 2017

Missed tech-talk... my apologies

by Esteban Lorenzano

Hi, I missed (2nd time) the tech talk of yesterday. Truth is that Iâm running trying to getting everything ready for release and I completely forget about it :( So, I think best is just to skip last monthâs tech-talk (it was already delayed once) and focus in currentâs one (and in releasing). cheers, Esteban

April 5, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0 (updated to April 03)

by Ben Coman

On Wed, Apr 5, 2017 at 2:16 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Pavel, > > On Tue, Apr 4, 2017 at 1:15 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> >> >> 2017-04-03 15:00 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> Hello, >>> >>> This are the things I believe still needs to be solved to be able to >>> release Pharo 6.0: >>> >>> VM: >>> === >>> - win32, cairo fonts problem (I submitted a new VM to test, I think this >>> is fixed :P) >>> - make all tests pass (there are still some failing tests when compiling >>> a new VM)/. >>> - libgit2: Still not there, Jan and Ben were trying and sent some >>> suggestions but I still didnât had the time to test it. >>> >>> Image: >>> ===== >>> >>> - iceberg still needs to go inside the image, Iâm running to release >>> version 0.4 (maybe this week?) and then we can integrate. >>> - I'm still convinced there is a leak. I need to check this in detail. >>> And of course some help on thisâ¦ Pavel?â¦ would be cool :) >>> >> >> I have found one memory leak related to subscription type mixing: >> https://pharo.fogbugz.com/f/cases/19911 >> >> Then I had here a really huge image with 1.2 GB with all known memory >> leaks solved. It was leaking because of Undeclared, after cleaning of them >> (Undeclared removeUnreferencedKeys) it shrinked to 59 MB. >> >> In this particular case it was caused by code like this: >> >> initialize >> super initialize. >> noBindingBlock := [ objectSpace nilObject ] >> >> because noBindingBlock was undeclared, it created a reference from >> globals (Undeclared) to a particular context with all mess it referenced. >> >> Not sure if we should make some action like clean Undeclared before every >> snapshot. But the case like this is quite obscure and the information that >> people should beware it should be enough. >> > > Cleaning Undeclared arbitrarily is a very bad idea. Undeclared is where > we can find and eliminate Undeclared variables. Just eliminating them from > Undeclared does not solve the problem. The variables are still referenced > in coded. But when one removes them from Undeclared they become harder to > find. > > Instead the right solution is > a) to have tests in the standard test suite that check that Undeclared is > empty. If Undeclared is not empty the test should fail. > b) in any packaging or release process that produces a clean image there > should be a check for Undeclared being empty, and the build should fail if > it is not empty. > c) Smalltalk programmers should understand how undeclared variables work > in Smalltalk: > > Variables are declared either in some global pool such as Smalltalk, > TextConstants or a class pool (the dictionary holding class variables), or > as instance variables of a class, or as arguments and temporary variables > of a method. These are the only variables in the language. When the > compiler sees a variable name it searches for it, first amongst arguments > and temporaries, second amongst instance variables, third amongst class > variables, fourth amongst the class's imported pools, fifth in globals > (Smalltalk) and finally in Undeclared. If the variable is not found in any > of these places then a binding is created in Undeclared and that is used to > implement the variable. So undeclared variables are compiled as globals in > Undeclared. > > Whenever a variable is declared in a global pool (Smalltalk, a shared pool > or a class pool) the compiler checks for a binding in Undeclared and uses > that if it exists. Adding a class declares the class's binding in > Smalltalk. So uses of variables before they are declared get fixed up on > declaration without having to recompile the entire system. This is how the > system manages circularities amongst classes. A reference to a class that > has yet to be installed will be compiled as a reference to a binding in > Undeclared. When the class is installed it is set as the value of the > Undeclared binding, and the binding is moved from Undeclared to Smalltalk. > > When an instance variable is defined in a class that changes the shape of > the class's instances and so the class's methods are recompiled and that > will bind any undeclared references to the instance variable correctly. > > So an entry in Undeclared is > a) an indication that somewhere there is a missing declaration > b) a place where one can look for references to the undeclared binding > (references in the dictionary inspector, and I hope the Glamour inspector, > that opens when one inspects Undeclared) > c) a simple mechanism for allowing circular references amongst classes > > So under no circumstances remove bindings from Undeclared unless there are > no references from code to those bindings. There is a method that does > this: > Undeclared removeUnusedBindings > > HTH > Very informative. Thanks for that insight. Maybe should capture it for Deep Into Pharo (but I'm off to bed right now) cheers -ben > > >> Cheers, >> -- Pavel >> >> >>> List is a lot smaller now :) >>> If everything goes well, we can target to release next week. >>> >>> Next: >>> - Test the new process and tape some videos explaining how we will >>> contribute with a bootstrapped process using github :) >>> >>> cheers! >>> Esteban >>> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

April 4, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0 (updated to April 03)

by Eliot Miranda

Hi Pavel, On Tue, Apr 4, 2017 at 1:15 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > 2017-04-03 15:00 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> Hello, >> >> This are the things I believe still needs to be solved to be able to >> release Pharo 6.0: >> >> VM: >> === >> - win32, cairo fonts problem (I submitted a new VM to test, I think this >> is fixed :P) >> - make all tests pass (there are still some failing tests when compiling >> a new VM)/. >> - libgit2: Still not there, Jan and Ben were trying and sent some >> suggestions but I still didnât had the time to test it. >> >> Image: >> ===== >> >> - iceberg still needs to go inside the image, Iâm running to release >> version 0.4 (maybe this week?) and then we can integrate. >> - I'm still convinced there is a leak. I need to check this in detail. >> And of course some help on thisâ¦ Pavel?â¦ would be cool :) >> > > I have found one memory leak related to subscription type mixing: > https://pharo.fogbugz.com/f/cases/19911 > > Then I had here a really huge image with 1.2 GB with all known memory > leaks solved. It was leaking because of Undeclared, after cleaning of them > (Undeclared removeUnreferencedKeys) it shrinked to 59 MB. > > In this particular case it was caused by code like this: > > initialize > super initialize. > noBindingBlock := [ objectSpace nilObject ] > > because noBindingBlock was undeclared, it created a reference from globals > (Undeclared) to a particular context with all mess it referenced. > > Not sure if we should make some action like clean Undeclared before every > snapshot. But the case like this is quite obscure and the information that > people should beware it should be enough. > Cleaning Undeclared arbitrarily is a very bad idea. Undeclared is where we can find and eliminate Undeclared variables. Just eliminating them from Undeclared does not solve the problem. The variables are still referenced in coded. But when one removes them from Undeclared they become harder to find. Instead the right solution is a) to have tests in the standard test suite that check that Undeclared is empty. If Undeclared is not empty the test should fail. b) in any packaging or release process that produces a clean image there should be a check for Undeclared being empty, and the build should fail if it is not empty. c) Smalltalk programmers should understand how undeclared variables work in Smalltalk: Variables are declared either in some global pool such as Smalltalk, TextConstants or a class pool (the dictionary holding class variables), or as instance variables of a class, or as arguments and temporary variables of a method. These are the only variables in the language. When the compiler sees a variable name it searches for it, first amongst arguments and temporaries, second amongst instance variables, third amongst class variables, fourth amongst the class's imported pools, fifth in globals (Smalltalk) and finally in Undeclared. If the variable is not found in any of these places then a binding is created in Undeclared and that is used to implement the variable. So undeclared variables are compiled as globals in Undeclared. Whenever a variable is declared in a global pool (Smalltalk, a shared pool or a class pool) the compiler checks for a binding in Undeclared and uses that if it exists. Adding a class declares the class's binding in Smalltalk. So uses of variables before they are declared get fixed up on declaration without having to recompile the entire system. This is how the system manages circularities amongst classes. A reference to a class that has yet to be installed will be compiled as a reference to a binding in Undeclared. When the class is installed it is set as the value of the Undeclared binding, and the binding is moved from Undeclared to Smalltalk. When an instance variable is defined in a class that changes the shape of the class's instances and so the class's methods are recompiled and that will bind any undeclared references to the instance variable correctly. So an entry in Undeclared is a) an indication that somewhere there is a missing declaration b) a place where one can look for references to the undeclared binding (references in the dictionary inspector, and I hope the Glamour inspector, that opens when one inspects Undeclared) c) a simple mechanism for allowing circular references amongst classes So under no circumstances remove bindings from Undeclared unless there are no references from code to those bindings. There is a method that does this: Undeclared removeUnusedBindings HTH > Cheers, > -- Pavel > > >> List is a lot smaller now :) >> If everything goes well, we can target to release next week. >> >> Next: >> - Test the new process and tape some videos explaining how we will >> contribute with a bootstrapped process using github :) >> >> cheers! >> Esteban >> > > -- _,,,^..^,,,_ best, Eliot

April 4, 2017