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

Code completion in Pharo - editing keywords

by komarlu2＠fit.cvut.cz

Hello again, I have finally worked out the keyword editing problem. I think it is not well written, I am still struggeling with many things that are as they are and basically still learning to read and adjust code. It is very hard for me to try to do that as I'm used to C#, C++, Java etc. Reading Smalltalk code in Pharo just seems to be so much more complex to me .. Anyway .. now it works only for UntypedModel, which is a problem still, that I have no idea how to fix at the moment. There should be two models with this I believe, but the NECModel class isn't written in the way that it could have multiple models (one for the receiver of the whole keyword and one for the receiver of the parameter of the previous part of the keyword .. .). If anyone would like to have a look and say what you think, what I'm doing wrong, what am I not seeing, please reply. MCHttpRepository location: 'http://smalltalkhub.com/mc/lukaskomarek/CodeCompletion_FIT_CTU/ main(http://smalltalkhub.com/mc/lukaskomarek/CodeCompletion_FIT_CTU/main)' user: '' password: '' Cheers, Lukas

April 6, 2017

Re: [Pharo-dev] Glamour Fast List selection bug or incorrect usage?

by Andrei Chis

Hi, On Tue, Apr 4, 2017 at 5:01 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > Hi, > > yes, it is better, but it does not work intuitively. Try the following: > > 1. execute your script, > 2. click on 4 (selection), > 3. click on 8 (selection), > 4. click on 4 (deselection), > 5. click on 4 (selection) > > You can see that the third list still keeps the number 8. It is necessary > to deselect 8 in order to see 4. > Indeed, this is not what you'd expect. > > This part explains to me how the transmit works: > > ``` > tabulator transmit > from: #one; to: #three; > from: #two; to: #three; > transformed: [ :x :y | y ifNil: [ x ] ifNotNil: [ y ] ]; > andShow: [ :a | > a fastList display: [ :x | Array with: x ] ]. > ``` > > By using #transformed: I can decide what to use (#one or #two). It is nice > feature! > > I think what I need is having to possibility to change the third list also > according to what list is active (#one or #two). > In the first screenshot, the first list is active (blue border). In the > second screenshot, the second list is active. > So I would like to update the third list according to the active one. > Is it possible? > Unfortunately this doesn't work out of the box. We'll need to implement something that can generate evens/populates a port when a presentation gets the focus. Cheers, Andrei > > > Thanks! > Juraj > > On Apr 3, 2017, at 18:53, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi, > > That's actually the default behavior, but I see there is also a bug. > Normally if you want to allow deselection in a presentation you should use > allowDeselection. Just I see there is a bug in the fast table renderer > because if I add #allowDeselection to the first presentation when clicking > again on the selected element the selection port is not cleared. If you use > #list instead of #fastList it works. > > I think you can get the desired behaviur using this code: > > ----------------------------------------------------------------- > tabulator := GLMTabulator new. > > tabulator column: #one; column: #two; column: #three. > > tabulator transmit to: #one; andShow: [ :composite | > composite list > allowDeselection; > display: [ :x | Array with: x ] ]. > tabulator transmit to: #two; andShow: [ :composite | > composite list > allowDeselection; > display: [ :x | Array with: 2 * x ] ]. > > tabulator transmit > from: #one; to: #three; > from: #two; to: #three; > transformed: [ :x :y | y ifNil: [ x ] ifNotNil: [ y ] ]; > andShow: [ :a | > a fastList display: [ :x | Array with: x ] ]. > > tabulator openOn: 4. > ----------------------------------------------------------------- > > > Cheers, > Andrei > > On Mon, Apr 3, 2017 at 9:35 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> > wrote: > >> Hi! >> >> If you create the following Glamour browser: >> >> ``` >> tabulator := GLMTabulator new. >> >> tabulator column: #one; column: #two; column: #three. >> >> tabulator transmit to: #one; andShow: [ :composite | >> composite fastList display: [ :x | Array with: x ] ]. >> tabulator transmit to: #two; andShow: [ :composite | >> composite fastList display: [ :x | Array with: 2 * x ] ]. >> >> tabulator transmit from: #one; to: #three; andShow: [ :a | >> a fastList display: [ :x | Array with: x ] ]. >> tabulator transmit from: #two; to: #three; andShow: [ :a | >> a fastList display: [ :x | Array with: x ] ]. >> >> tabulator openOn: 4. >> ``` >> >> You will get the following browser: >> >> <Screen Shot 2017-04-03 at 16.30.28.png> >> >> if you then select 4, the third list appears. If you then select 8, the >> value is changed: >> >> <Screen Shot 2017-04-03 at 16.29.38.png> >> >> But since then, the third list does not change. It stays with 8 value >> forever. >> >> Do I miss something? Should I define it differently? >> Or if it is a bug: Can you give me insights how to fix it? >> >> Tested in the latest Pharo 6. >> >> Thanks! >> Juraj >> >> > >

April 6, 2017

Re: [Pharo-dev] Fogbugz notifications auto-subscribe

by Alistair Grant

Hi Ben, On Thu, Apr 06, 2017 at 09:03:58AM +0800, Ben Coman wrote: > Just in case anyone is not aware, you can auto-subscribe > to Issues that you comment on. > > http://help.fogcreek.com/subscriptions-receive-notifications-for-changes-to… > > cheers -ben Many thanks for point this out. :-) Cheers, Alistair

April 6, 2017

Fogbugz notifications auto-subscribe

by Ben Coman

Just in case anyone is not aware, you can auto-subscribe to Issues that you comment on. http://help.fogcreek.com/subscriptions-receive-notifications-for-changes-to… cheers -ben

April 6, 2017

Re: [Pharo-dev] ftp repositories broken

by Henrik Sperre Johansen

Eliot Miranda-2 wrote > On Tue, Apr 4, 2017 at 10:00 AM, Denis Kudriashov < > dionisiydk@ > > > wrote: > >> >> 2017-04-04 18:45 GMT+02:00 Esteban Lorenzano < > estebanlm@ > >: >> >>> > 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. >> > > Not yet. We are close. Last week I got angry with Esteban because I > thought that the joe was stalled because Pharo didn't want to move to > opensmalltalk-vm, but I over reacted. One of the issues preventing the > move was indeed this primitive and the fact that someone, without thinking > to talk to anyone working with the VM, renamed the primitive, and then > someone put it on the wrong class. Esteban and I have spent some hours > trying to work around such issues. I wish people would be more > considerate. > ,,,^..^,,,_ > best, Eliot You'd have to talk to the Sophie people ;) http://forum.world.st/VMMaker-Inlining-loop-with-MiscPrimitivesPlugin-on-Ph… And "not talking to anyone working on the vm" is somewhat of an exaggeration, there were multiple other threads on the topic at the time, including the one where Andreas fixed the bug in the primitive the workaround wrapper/rename was meant to avoid; http://forum.world.st/latest-vmmaker-wont-run-with-pharo-1-1-1-dev-td303022… IIRC, I kept checking periodically if stable released vm's including the fix were available on all platforms it so the workaround could be removed, but after a year and a half or so without a new stable windows release, I sort of gave up/forgot about it :( +1 to renaming it back now and removing the fluff in the Pharo image. It's been 7 years since the issue in the primitive (which the extra wrapping of findSubstring: worked around) was fixed, and since opensmalltalk-vm got off the ground, there hasn't been a VM in general use that didn't include it. Cheers, Henry -- View this message in context: http://forum.world.st/ftp-repositories-broken-tp4941194p4941383.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 5, 2017

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

by Peter Uhnak

Or if you want yet another crash in fresh image and latest vm... (no crash.dmp of course) Unhandled exception at 0x0048B197 in Pharo.exe: 0xC0000005: Access violation reading location 0x00000075. registers EAX=0000003F EBX=00ADCA14 ECX=00000071 EDX=00ADD241 ESI=00372000 EDI=00000071 EIP=0048B197 ESP=00ADC0B4 EBP=00ADC11C EFL=00210206 0x00000075=00000000 disasm 0048B165 ret 0048B166 sub ebx,dword ptr [edi+108h] 0048B16C mov dword ptr [esi+8],ebx 0048B16F jmp 0048B134 0048B171 mov edx,57D40Bh 0048B176 jmp 0048B156 0048B178 push ebp 0048B179 push edi 0048B17A push esi 0048B17B push ebx 0048B17C mov edi,dword ptr [esp+14h] 0048B180 mov ebp,dword ptr [esp+18h] 0048B184 mov esi,dword ptr fs:[18h] 0048B18B mov eax,dword ptr [esp+1Ch] 0048B18F test eax,eax 0048B191 jle 0048B246 ---> 0048B197 mov edx,dword ptr [edi+4] <--- 0048B19A test edx,edx 0048B19C je 0048B246 0048B1A2 mov dword ptr [ebp],edx 0048B1A5 mov edx,dword ptr [edi] 0048B1A7 cmp edx,dword ptr [esi+4] 0048B1AA jae 0048B24A 0048B1B0 mov ecx,edi 0048B1B2 mov eax,1 0048B1B7 test byte ptr [esp+1Ch],1 0048B1BC jne 0048B228 0048B1BE cmp edi,edx 0048B1C0 setae bl 0048B1C3 mov ecx,ebx 0048B1C5 or bl,cl 0048B1C7 jne 0048B241 0048B1C9 test dl,3 0048B1CC jne 0048B241 0048B1CE mov ebx,dword ptr [edx+4] 0048B1D1 test ebx,ebx 0048B1D3 je 0048B241 0048B1D5 mov eax,2 0048B1DA mov dword ptr [ebp+eax*4-4],ebx 0048B1DE mov ebx,dword ptr [edx] 0048B1E0 mov ecx,edx 0048B1E2 cmp ebx,dword ptr [esi+4] 0048B1E5 jae 0048B241 0048B1E7 mov edx,ebx 0048B1E9 jmp 0048B228 0048B1EB mov ebx,dword ptr [edx+4] 0048B1EE test ebx,ebx 0048B1F0 je 0048B241 0048B1F2 add eax,1 0048B1F5 mov dword ptr [ebp+eax*4-4],ebx 0048B1F9 mov ecx,dword ptr [edx] 0048B1FB cmp ecx,dword ptr [esi+4] 0048B1FE jae 0048B241 0048B200 cmp edi,ecx 0048B202 setae bl 0048B205 cmp edx,ecx 0048B207 setae dl 0048B20A or bl,dl 0048B20C jne 0048B241 0048B20E test cl,3 0048B211 jne 0048B241 0048B213 mov ebx,dword ptr [ecx+4] 0048B216 test ebx,ebx 0048B218 je 0048B241 0048B21A add eax,1 0048B21D mov dword ptr [ebp+eax*4-4],ebx 0048B221 mov edx,dword ptr [ecx] 0048B223 cmp edx,dword ptr [esi+4] 0048B226 jae 0048B241 0048B228 cmp edi,edx 0048B22A setae bl 0048B22D cmp ecx,edx 0048B22F setae cl 0048B232 or bl,cl 0048B234 jne 0048B241 0048B236 test dl,3 0048B239 jne 0048B241 0048B23B cmp dword ptr [esp+1Ch],eax 0048B23F jne 0048B1EB 0048B241 pop ebx 0048B242 pop esi 0048B243 pop edi 0048B244 pop ebp 0048B245 ret On Wed, Apr 05, 2017 at 03:45:15PM +0200, Peter Uhnak wrote: > explicit call to garbage collect crashes the image (crash.dmp attached), > so I think that in this case I somehow corrupted the image (with metalinks presumably) > > On Wed, Apr 05, 2017 at 03:39:39PM +0200, Peter Uhnak wrote: > > Can confirm that the latest (Apr 4) VM crashes too. > > > > I am not sure on what code this is crashing, but I am experiencing some odd behavior from metalinks, so maybe I broke something there (I was using metalinks a lot before the crash)... will investigate further. > > > > Peter > > > > > > On Wed, Apr 05, 2017 at 01:46:30PM +0200, Peter Uhnak wrote: > > > 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) > > > > > >> >>> > > > > > >> >> > > > > > >> >> > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > Wed Apr 05 15:41:01 2017 > > Exception code: C0000005 > Exception addr: 0041FCB4 > Access violation (read access) at 2B31DCE0 > EAX:02800000 EBX:00000001 ECX:2B31DCE0 EDX:0E804909 > ESI:00000004 EDI:01004909 EBP:1C500420 ESP:00ADD080 > EIP:0041FCB4 EFL:00210246 > FP Control: 0000027F > FP Status: 00000420 > FP Tag: 0000FFFF > > > Crashed in the VM thread > > > > Hardware information: > Manufacturer: Unknown > Model: Unknown > Number of processors: 4 > Page size: 4096 > > Memory Information (upon launch): > Physical Memory Size: 4194303 kbytes > Physical Memory Free: 4194303 kbytes > Page File Size: 4194303 kbytes > Page File Free: 4194303 kbytes > Virtual Memory Size: 4194176 kbytes > Virtual Memory Free: 4094764 kbytes > Memory Load: 23 percent > > Processor 0: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz > Identifier: Intel64 Family 6 Model 94 Stepping 3 > ~MHZ: 2712 > > Processor 1: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz > Identifier: Intel64 Family 6 Model 94 Stepping 3 > ~MHZ: 2712 > > Processor 2: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz > Identifier: Intel64 Family 6 Model 94 Stepping 3 > ~MHZ: 2712 > > Processor 3: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz > Identifier: Intel64 Family 6 Model 94 Stepping 3 > ~MHZ: 2712 > > Operating System: Windows 10 Home (Build 14393 ) > > SP major version: 0 > SP minor version: 0 > Suite mask: 300 > Product type: 1 > > Display Information: > Graphics adapter name: NVIDIA GeForce GTX 1060 6GB > Primary monitor resolution: 1920 x 1200 > > Device: NVIDIA GeForce GTX 1060 6GB > Memory Size: 0xFFF00000 > > Driver Versions: > C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvd3dumx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvwgf2umx: > > VM Version: Cog Spur VM 5.0 (release) from Apr 4 2017 > Compiler: gcc 5.4.0 > Interpreter Build: CoInterpreter * VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 4 2017 > Cogit Build: StackToRegisterMappingCogit * VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 4 2017 > Source Version: VM: 201704041239 https://github.com/pharo-project/pharo-vm.git $ Date: Tue Apr 4 14:39:42 2017 +0200 $ > Plugins: 201704041239 https://github.com/pharo-project/pharo-vm.git $ > > Current byte code: 210 > Primitive index: 130 > > Loaded plugins: > ZipPlugin * VMMaker.oscog-eem.2188 (i) > JPEGReadWriter2Plugin * VMMaker.oscog-eem.2188 (i) > B2DPlugin * VMMaker.oscog-eem.2188 (i) > BitBltPlugin * VMMaker.oscog-eem.2188 (i) > FT2Plugin Freetype-Plugin-EstebanLorenzano.70 (e) > FilePlugin * VMMaker.oscog-eem.2188 (i) > MiscPrimitivePlugin * VMMaker.oscog-eem.2188 (i) > LargeIntegers v2.0 * VMMaker.oscog-eem.2188 (i) > LocalePlugin * VMMaker.oscog-eem.2188 (i) > SecurityPlugin * VMMaker.oscog-eem.2188 (i) > > Module information: > 00400000 - 00703000: C:\Applications\Pharo6VM\Pharo.exe > 00b90000 - 00bb3000: C:\WINDOWS\SYSTEM32\WINMMBASE.dll > 10000000 - 1002b000: C:\WINDOWS\System32\cbfsMntNtf6.dll > 10100000 - 106c4c70: CogCode > 553c0000 - 555bf000: C:\Users\uhnak\AppData\Local\Microsoft\OneDrive\17.3.6798.0207\FileSyncShell.dll > 55650000 - 556d3000: C:\Windows\System32\PortableDeviceApi.dll > 557d0000 - 557e2000: C:\WINDOWS\system32\mssprxy.dll > 557f0000 - 55914000: C:\WINDOWS\system32\NetworkExplorer.dll > 55920000 - 5593b000: C:\Windows\System32\DevDispItemProvider.dll > 55940000 - 55998000: C:\Windows\System32\PlayToDevice.dll > 559a0000 - 559e2000: C:\Windows\System32\dlnashext.dll > 559f0000 - 55b76000: C:\Windows\System32\ActXPrxy.dll > 55b80000 - 55c2f000: C:\WINDOWS\system32\Windows.Storage.Search.dll > 55c30000 - 55d82000: C:\Windows\System32\uiautomationcore.dll > 55d90000 - 55ec6000: C:\Windows\System32\Windows.Globalization.dll > 56210000 - 5622a000: C:\WINDOWS\System32\davclnt.dll > 56230000 - 562b5000: C:\WINDOWS\System32\StructuredQuery.dll > 56350000 - 563b7000: C:\WINDOWS\SYSTEM32\msvcp110_win.dll > 56430000 - 56442000: C:\WINDOWS\System32\ntlanman.dll > 56450000 - 56493000: C:\Windows\System32\thumbcache.dll > 56f60000 - 56fa3000: C:\WINDOWS\System32\WINSTA.dll > 5c0e0000 - 5c10a000: C:\WINDOWS\SYSTEM32\RTWorkQ.DLL > 5c5f0000 - 5c703000: C:\WINDOWS\SYSTEM32\MFPlat.DLL > 5cf40000 - 5cf92000: C:\Windows\System32\Bcp47Langs.dll > 5cfa0000 - 5d3dc000: C:\WINDOWS\system32\explorerframe.dll > 5d930000 - 5d988000: C:\WINDOWS\System32\MMDevApi.dll > 5da10000 - 5db23000: C:\WINDOWS\system32\dcomp.dll > 5db30000 - 5db74000: C:\WINDOWS\system32\dataexchange.dll > 5db80000 - 5ddb0000: C:\WINDOWS\system32\d3d11.dll > 5df90000 - 5dfe4000: C:\WINDOWS\system32\OLEACC.dll > 62d30000 - 62e1d000: C:\WINDOWS\SYSTEM32\DDRAW.dll > 62f00000 - 62fe0000: C:\WINDOWS\SYSTEM32\OPENGL32.DLL > 63940000 - 6394e000: C:\Applications\Pharo6VM\iconv.dll > 646d0000 - 64838000: C:\WINDOWS\system32\DUI70.dll > 64840000 - 64931000: C:\WINDOWS\system32\twinapi.appcore.dll > 64b40000 - 64b54000: C:\Applications\Pharo6VM\libwinpthread-1.dll > 669d0000 - 669db000: C:\WINDOWS\System32\DAVHLPR.dll > 669e0000 - 66a05000: C:\WINDOWS\SYSTEM32\globinputhost.dll > 66a10000 - 66a8b000: C:\WINDOWS\system32\DUser.dll > 66b00000 - 66b06000: C:\WINDOWS\SYSTEM32\SHFolder.dll > 66b50000 - 66b59000: C:\WINDOWS\System32\drprov.dll > 67080000 - 6713b000: C:\Applications\Pharo6VM\libfreetype.dll > 679c0000 - 67a81000: C:\WINDOWS\SYSTEM32\ntshrui.dll > 69580000 - 69603000: C:\WINDOWS\system32\dxgi.dll > 6a780000 - 6a7ad000: C:\Applications\Pharo6VM\FT2Plugin.DLL > 6b7e0000 - 6b81f000: C:\WINDOWS\SYSTEM32\policymanager.dll > 6b820000 - 6b845000: C:\WINDOWS\SYSTEM32\dinput.dll > 6b990000 - 6ba11000: C:\WINDOWS\SYSTEM32\sxs.dll > 6ba20000 - 6ba3c000: C:\WINDOWS\SYSTEM32\srvcli.dll > 6ba50000 - 6ba75000: C:\WINDOWS\SYSTEM32\GLU32.dll > 6c560000 - 6c56d000: C:\WINDOWS\SYSTEM32\LINKINFO.dll > 6c940000 - 6caad000: C:\Applications\Pharo6VM\SDL2.dll > 6d0c0000 - 6d0dd000: C:\Applications\Pharo6VM\libgcc_s_sjlj-1.dll > 6e140000 - 6e161000: C:\WINDOWS\SYSTEM32\Cabinet.dll > 6e810000 - 6e8fe000: C:\Users\uhnak\AppData\Local\Microsoft\OneDrive\17.3.6798.0207\MSVCR120.dll > 6e940000 - 6eaae000: C:\WINDOWS\SYSTEM32\WindowsCodecs.dll > 6f890000 - 6faf6000: C:\WINDOWS\SYSTEM32\WININET.dll > 6ff50000 - 6ffc1000: C:\Users\uhnak\AppData\Local\Microsoft\OneDrive\17.3.6798.0207\MSVCP120.dll > 6ffd0000 - 70062000: C:\WINDOWS\SYSTEM32\apphelp.dll > 70340000 - 7038f000: C:\Users\uhnak\AppData\Local\Microsoft\OneDrive\17.3.6798.0207\Telemetry.dll > 70390000 - 7059a000: C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.14393.953_none_89c2555adb023171\comctl32.dll > 706c0000 - 706cf000: C:\WINDOWS\SYSTEM32\cscapi.dll > 70760000 - 70778000: C:\Users\uhnak\AppData\Local\Microsoft\OneDrive\17.3.6798.0207\LoggingPlatform.DLL > 707f0000 - 7080a000: C:\Windows\System32\USERENV.dll > 70980000 - 70acf000: C:\WINDOWS\SYSTEM32\PROPSYS.dll > 70e40000 - 70e4a000: C:\WINDOWS\SYSTEM32\Secur32.dll > 70e50000 - 70e5b000: C:\WINDOWS\System32\netutils.dll > 70ec0000 - 70ee2000: C:\WINDOWS\System32\DEVOBJ.dll > 70f30000 - 70f38000: C:\WINDOWS\SYSTEM32\WSOCK32.dll > 70f40000 - 70fe0000: C:\WINDOWS\SYSTEM32\WINHTTP.dll > 71230000 - 71240000: C:\WINDOWS\System32\wkscli.dll > 712b0000 - 712b7000: C:\WINDOWS\SYSTEM32\DCIMAN32.dll > 71330000 - 713c4000: C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.14393.447_none_5507ded2cb4f7f4c\COMCTL32.dll > 71440000 - 71449000: C:\WINDOWS\SYSTEM32\atlthunk.dll > 71450000 - 7146f000: C:\WINDOWS\system32\dwmapi.dll > 720f0000 - 7210b000: C:\WINDOWS\system32\bcrypt.dll > 73420000 - 73436000: C:\WINDOWS\SYSTEM32\MPR.dll > 73440000 - 7347d000: C:\WINDOWS\SYSTEM32\edputil.dll > 73670000 - 73694000: C:\WINDOWS\SYSTEM32\WINMM.DLL > 736a0000 - 73715000: C:\WINDOWS\system32\uxtheme.dll > 73e10000 - 73e18000: C:\WINDOWS\SYSTEM32\VERSION.dll > 740a0000 - 740aa000: C:\WINDOWS\System32\CRYPTBASE.dll > 740b0000 - 740ce000: C:\WINDOWS\System32\SspiCli.dll > 740d0000 - 741b0000: C:\WINDOWS\System32\KERNEL32.DLL > 741b0000 - 74244000: C:\WINDOWS\System32\OLEAUT32.dll > 74250000 - 74385000: C:\WINDOWS\System32\MSCTF.dll > 74390000 - 74396000: C:\WINDOWS\System32\PSAPI.DLL > 743a0000 - 74485000: C:\WINDOWS\System32\COMDLG32.DLL > 74490000 - 744d5000: C:\WINDOWS\System32\powrprof.dll > 744e0000 - 7453a000: C:\WINDOWS\System32\bcryptPrimitives.dll > 74540000 - 745a3000: C:\WINDOWS\System32\WS2_32.dll > 745b0000 - 74751000: C:\WINDOWS\System32\KERNELBASE.dll > 748d0000 - 74a4d000: C:\WINDOWS\System32\CRYPT32.dll > 74ab0000 - 74b71000: C:\WINDOWS\System32\RPCRT4.dll > 74b80000 - 74bb6000: C:\WINDOWS\System32\cfgmgr32.dll > 74bc0000 - 74c37000: C:\WINDOWS\System32\ADVAPI32.dll > 74c40000 - 74c9b000: C:\WINDOWS\System32\coml2.dll > 74ca0000 - 74d28000: C:\WINDOWS\System32\shcore.dll > 74d30000 - 74d55000: C:\WINDOWS\System32\IMM32.DLL > 74d60000 - 74e1e000: C:\WINDOWS\System32\msvcrt.dll > 74e20000 - 74e61000: C:\WINDOWS\System32\sechost.dll > 74e70000 - 74fcf000: C:\WINDOWS\System32\USER32.dll > 74fd0000 - 75014000: C:\WINDOWS\System32\WINTRUST.dll > 75020000 - 7558e000: C:\WINDOWS\System32\windows.storage.dll > 75590000 - 75670000: C:\WINDOWS\System32\ucrtbase.dll > 75670000 - 7567e000: C:\WINDOWS\System32\MSASN1.dll > 75680000 - 75891000: C:\WINDOWS\System32\combase.dll > 758a0000 - 758af000: C:\WINDOWS\System32\profapi.dll > 75980000 - 7598d000: C:\WINDOWS\System32\kernel.appcore.dll > 75990000 - 759d6000: C:\WINDOWS\System32\SHLWAPI.dll > 759e0000 - 75b3b000: C:\WINDOWS\System32\gdi32full.dll > 75b40000 - 75bc4000: C:\WINDOWS\System32\clbcatq.dll > 75bd0000 - 75cba000: C:\WINDOWS\System32\ole32.dll > 75cc0000 - 75d3b000: C:\WINDOWS\System32\msvcp_win.dll > 75d50000 - 7615b000: C:\WINDOWS\System32\SETUPAPI.dll > 76160000 - 76175000: C:\WINDOWS\System32\win32u.dll > 76180000 - 77559000: C:\WINDOWS\System32\SHELL32.dll > 77560000 - 7758b000: C:\WINDOWS\System32\GDI32.dll > 775f0000 - 77773000: C:\WINDOWS\SYSTEM32\ntdll.dll > > Primitive trace: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > **StackOverflow** > replaceFrom:to:with:startingAt: > shallowCopy > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > replaceFrom:to:with:startingAt: > compare:with:collated: > instVarAt:put: > replaceFrom:to:with:startingAt: > compare:with:collated: > instVarAt:put: > replaceFrom:to:with:startingAt: > compare:with:collated: > instVarAt:put: > species > **StackOverflow** > stringHash:initialHash: > stringHash:initialHash: > stringHash:initialHash: > stringHash:initialHash: > stringHash:initialHash: > stringHash:initialHash: > stringHash:initialHash: > stringHash:initialHash: > stringHash:initialHash: > basicNew > stringHash:initialHash: > basicNew > fullCheck > basicNew > basicNew > basicNew > basicNew > basicNew > **StackOverflow** > basicNew > stringHash:initialHash: > basicNew > push: > stringHash:initialHash: > stringHash:initialHash: > findSubstring:in:startingAt:matchTable: > **PrimitiveFailure** > numArgs > numArgs > numArgs > numArgs > numArgs > numArgs > numArgs > numArgs > numArgs > numArgs > numArgs > numArgs > numArgs > numArgs > indexOfAscii:inString:startingAt: > stringHash:initialHash: > stringHash:initialHash: > * > * > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > isEmpty > bitShift: > bitShift: > numTemps > numTemps > numTemps > asBit > asBit > **StackOverflow** > replaceFrom:to:with:startingAt: > initialize > newMethod:header: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > size > at: > at:put: > basicNew > with: > replaceFrom:to:with:startingAt: > at:put: > at:put: > at:put: > objectAt:put: > objectAt:put: > objectAt:put: > objectAt:put: > withIndexDo: > numTemps > numTemps > numTemps > bitAnd: > **PrimitiveFailure** > bitAnd: > **PrimitiveFailure** > bitOr: > **PrimitiveFailure** > bitOr: > new: > objectAt: > at:put: > objectAt: > at:put: > objectAt: > at:put: > objectAt: > at:put: > class > objectAt:put: > stringHash:initialHash: > objectAt:put: > withArgs:executeMethod: > basicAt: > value: > value > **StackOverflow** > basicIdentityHash > basicSize > species > basicNew: > basicAt: > basicAt:put: > species > basicNew: > basicReplaceFrom:to:with:startingAt: > do: > value: > value: > startIndexFor: > startIndexFor: > at: > at: > replaceFrom:to:with:startingAt: > at: > basicAt: > at: > at: > expire > at: > at: > primitiveGarbageCollect > **FullGC** > > > Stack backtrace: > [0041FCB4] ??? + 0x1fcb4 in Pharo.exe > [03800000] ??? + 0x0 in (null) > > > Smalltalk stack dump: > 0xae9060 I SmalltalkImage>garbageCollect 0x10bc6d90: a(n) SmalltalkImage > 0xae9078 M UndefinedObject>DoIt 0x106c4c70: a(n) UndefinedObject > 0xae90a8 I OpalCompiler>evaluate 0x103847f8: a(n) OpalCompiler > 0xae90d4 I RubSmalltalkEditor>evaluate:andDo: 0x1029bd48: a(n) RubSmalltalkEditor > 0xae90fc I RubSmalltalkEditor>highlightEvaluateAndDo: 0x1029bd48: a(n) RubSmalltalkEditor > 0xae911c M [] in GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>actOnHighlightAndEvaluate: 0x102cd918: a(n) GLMMorphicPharoScriptRenderer > 0xae9134 M RubEditingArea(RubAbstractTextArea)>handleEdit: 0x1029ae60: a(n) RubEditingArea > 0xae9154 M [] in GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>actOnHighlightAndEvaluate: 0x102cd918: a(n) GLMMorphicPharoScriptRenderer > 0xae9174 M WorldState>runStepMethodsIn: 0x118ed178: a(n) WorldState > 0xae9190 M WorldMorph>runStepMethods 0x111c7e68: a(n) WorldMorph > 0xae91a8 M WorldState>doOneCycleNowFor: 0x118ed178: a(n) WorldState > 0xae91c4 M WorldState>doOneCycleFor: 0x118ed178: a(n) WorldState > 0xae91e0 M WorldMorph>doOneCycle 0x111c7e68: a(n) WorldMorph > 0xae91f8 M WorldMorph class>doOneCycle 0x111afdb8: a(n) WorldMorph class > 0xae9210 M [] in FDMorphicUIManager(MorphicUIManager)>spawnNewProcess 0x1ef6ef88: a(n) FDMorphicUIManager > 0xae9230 I [] in BlockClosure>newProcess 0x1efc4670: a(n) BlockClosure

April 5, 2017

[pharo-project/pharo-core]

by GitHub

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

April 5, 2017

[pharo-project/pharo-core] 142da6: 60461

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 142da6254d4c122f4f302064aff12ca489e5460b https://github.com/pharo-project/pharo-core/commit/142da6254d4c122f4f302064… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-04-05 (Wed, 05 Apr 2017) Changed paths: M ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic versions/stable_.st A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F26%5F7_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60460.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60461.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60460.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60461.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M UnifiedFFI.package/FFIExternalStructureFieldParser.class/instance/parsing/parseFields_structure_.st A UnifiedFFI.package/FFIExternalStructureReferenceHandle.class/instance/accessing/replaceFrom_to_with_startingAt_.st R UnifiedFFI.package/FFIExternalStructureReferenceHandle.class/instance/as yet unclassified/replaceFrom_to_with_startingAt_.st A UnifiedFFI.package/FFIExternalStructureType.class/instance/accessing/callbackValueFor_at_.st M UnifiedFFI.package/FFIExternalStructureType.class/instance/private/basicHandle_at_put_.st A UnifiedFFI.package/FFILibrary.class/instance/accessing platform/unix32ModuleName.st A UnifiedFFI.package/FFILibrary.class/instance/accessing platform/unix64ModuleName.st M UnifiedFFI.package/FFILibrary.class/instance/accessing platform/unixModuleName.st R UnifiedFFI.package/FFILibrary.class/instance/as yet unclassified/ffiLibraryName.st A UnifiedFFI.package/FFILibrary.class/instance/library path/ffiLibraryName.st A UnifiedFFI.package/extension/Unix32Platform/instance/ffiModuleName_.st A UnifiedFFI.package/extension/Unix64Platform/instance/ffiModuleName_.st Log Message: ----------- 60461 19918 split unixModuleName into unix32ModuleName and unix64ModuleName https://pharo.fogbugz.com/f/cases/19918 http://files.pharo.org/image/60/60461.zip

April 5, 2017

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

by Peter Uhnak

explicit call to garbage collect crashes the image (crash.dmp attached), so I think that in this case I somehow corrupted the image (with metalinks presumably) On Wed, Apr 05, 2017 at 03:39:39PM +0200, Peter Uhnak wrote: > Can confirm that the latest (Apr 4) VM crashes too. > > I am not sure on what code this is crashing, but I am experiencing some odd behavior from metalinks, so maybe I broke something there (I was using metalinks a lot before the crash)... will investigate further. > > Peter > > > On Wed, Apr 05, 2017 at 01:46:30PM +0200, Peter Uhnak wrote: > > 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

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

by Peter Uhnak

Can confirm that the latest (Apr 4) VM crashes too. I am not sure on what code this is crashing, but I am experiencing some odd behavior from metalinks, so maybe I broke something there (I was using metalinks a lot before the crash)... will investigate further. Peter On Wed, Apr 05, 2017 at 01:46:30PM +0200, Peter Uhnak wrote: > 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