- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Good way to promote Smalltalk

by philippe.back＠highoctane.be

Le 24 mars 2017 03:03, "Ben Coman" <btc(a)openinworld.com> a Ã©crit : I was having a browse of the practice problems of Google's Code Jam and it strikes me that it would be useful to have a competition toolset for common tasks like: * interactively parsing text input data into objects * dealing with test cases * visualizing the input and output data to help cognitively understand the problem & solution. * producing a source code list in a suitable form for submission Definitely. And being deployable easily. Phil [1] https://code.google.com/codejam/contest/32003/dashboard#s=p0 cheers -ben On Fri, Mar 24, 2017 at 7:30 AM, Ben Coman <btc(a)openinworld.com> wrote: > It certainly makes a quantifiable measure of performance. > cheers -ben > > On Fri, Mar 24, 2017 at 12:57 AM, askoh <askoh(a)askoh.com> wrote: >> Being able to shine in software competitions is a very good way for Smalltalk >> to get exposure. We should present our technologies as such competitions as >> much as possible. Enjoy the case below. >> http://www.cincomsmalltalk.com/main/2017/03/one-cincom- engineer-got-450-programmers-bite-smalltalk/ >> >> Aik-Siong Koh >> >> >> >> -- >> View this message in context: http://forum.world.st/Good- way-to-promote-Smalltalk-tp4939758.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>

March 24, 2017

Re: [Pharo-dev] How to install Iceberg?

by Stephan Eggermont

On 23/03/17 21:54, Christophe Demarey wrote: > Hi Alex, > > the master branch is quite old. > Please use dev-0.4 branch with the latest stable VM. How? Metacello new baseline: 'Iceberg'; repository: 'github://npasserini/iceberg:dev-0.4'; load

March 24, 2017

Re: [Pharo-dev] Good way to promote Smalltalk

by Ben Coman

I was having a browse of the practice problems of Google's Code Jam and it strikes me that it would be useful to have a competition toolset for common tasks like: * interactively parsing text input data into objects * dealing with test cases * visualizing the input and output data to help cognitively understand the problem & solution. * producing a source code list in a suitable form for submission [1] https://code.google.com/codejam/contest/32003/dashboard#s=p0 cheers -ben On Fri, Mar 24, 2017 at 7:30 AM, Ben Coman <btc(a)openinworld.com> wrote: > It certainly makes a quantifiable measure of performance. > cheers -ben > > On Fri, Mar 24, 2017 at 12:57 AM, askoh <askoh(a)askoh.com> wrote: >> Being able to shine in software competitions is a very good way for Smalltalk >> to get exposure. We should present our technologies as such competitions as >> much as possible. Enjoy the case below. >> http://www.cincomsmalltalk.com/main/2017/03/one-cincom-engineer-got-450-pro… >> >> Aik-Siong Koh >> >> >> >> -- >> View this message in context: http://forum.world.st/Good-way-to-promote-Smalltalk-tp4939758.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>

March 24, 2017

Re: [Pharo-dev] Good way to promote Smalltalk

by Ben Coman

It certainly makes a quantifiable measure of performance. cheers -ben On Fri, Mar 24, 2017 at 12:57 AM, askoh <askoh(a)askoh.com> wrote: > Being able to shine in software competitions is a very good way for Smalltalk > to get exposure. We should present our technologies as such competitions as > much as possible. Enjoy the case below. > http://www.cincomsmalltalk.com/main/2017/03/one-cincom-engineer-got-450-pro… > > Aik-Siong Koh > > > > -- > View this message in context: http://forum.world.st/Good-way-to-promote-Smalltalk-tp4939758.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

March 23, 2017

Re: [Pharo-dev] inspector performance improvement

by Andrei Chis

Hi Henry, On Thu, Mar 23, 2017 at 10:49 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > I guess I'm late to the party, downloaded the latest Moose image today, > compared to Pharo5/6, it's night and day! > Browsing large collections is quicker than I can ever remember, if emails > had emoticons, there'd be a :partyhat: right here, great job! > > You're probably aware already, but there's an issue with the indexes for > the items tab when collections contain the same object multiple times, say > Yes we know this issue. It's actually fixed in Pharo, but it seems that I forgot to port the slice also to the repo of the inspector. Will do that tomorrow. > > o := Object new. > oc := OrderedCollection new: 2. > 1 to: 2 do: [:i | oc add: o]. > oc inspect > > or > > ba := (ByteArray new: 20000) inspect. > 0 to: 19999 do: [:i | ba at: i + 1 put: i \\ 255 + 1]. > ba inspect. > > Finding a solution that avoids doing indexOf: lookups, but pass along the > index instead when needed would be nice ;) > That's actually how the view for SequenceableCollection objects works; this problem is related to caching. > > The second example also highlight that there seems to be a (legacy?) > restriction of 10k entries in the raw view; the list jumps from index 5000 > -> 15001, this shouldn't be necessary anymore, right?. > In Pharo 5 the limit was 42 :). We increased it in Pharo 6 to 10k as we thought it is good enough. The 'Items' presentation however always displays the entire number of elements. > > *EDIT* After some digging, and testing with a large collection where the > limit is raised, I can see why it's there... > Find attached some improvements to FT that should (at least act as a PoC > that it's possible to) improve performance enough with large trees to > possibly remove indexableDisplayLimit entirely. > Tested by inspecting a 2M ByteArray, while opening the tab took ~5 secs, > navigation/scrolling afterwards was smooth sailing > It's definitely possible to eliminate the indexableDisplayLimit. One solution is to use a lazy model that only computes visible items for all collection presentations. I see that your solution plays with #visibleChildren. That's definitely a way to improve the tree widget. We'll look at this more for Pharo 7. If you made it so far you can also give the automatic refresh of the Raw view a try :) (GTInspector enableStepRefresh). Cheers, Andrei > Cheers, > Henry > > > > On 13 Feb 2017, at 11:56 , Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > > > > On Sun, Feb 12, 2017 at 5:07 PM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> Any chance for this to run on a 5.0? > > > > There are two main changes: moved inspector to fast table and some > > fixes in the glamour renderer. > > Moving the changes for the glamour renderer should be straightforward. > > I can point you to the list of relevant commits if you want to make a > > slice (We'll just need afterwards to also update > > ConfigurationOfGlamourCore to still work for Pharo 5) > > > > The FastTable changes could require more work but that should also be > > doable. However, now we still have some issues to fix there so that's > > not done for the moment. > > > > > > Cheers, > > Andrei > > > > > >> > >> Phil > >> > >> On Sun, Feb 12, 2017 at 3:13 PM, stepharong <stepharong(a)free.fr> wrote: > >>> > >>> Great job!!!! > >>> It feels lot snappier :) > >>> Now it is a real pleasure to navigate objects. > >>> This is nice to see that you are paying attention because the engine is > >>> getting faster and this is important > >>> that the tools do not eat all the power by accident. > >>> Tx a lot > >>> > >>> > >>> On Sat, 11 Feb 2017 21:31:56 +0100, Tudor Girba <tudor(a)tudorgirba.com> > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> Andrei and Alex did a great job at improving the performance and > >>>> scalability of the inspector. > >>>> > >>>> There are a couple of main improvements: > >>>> - Added FastTable support for the Raw presentation for all objects. > This > >>>> implied completing the support for the tree presentation binding to > fast > >>>> table. > >>>> - Moved the Items presentation for collections to FastTable. > >>>> - Improved the rendering of Glamour to no longer rely on the default > >>>> Morph>>#adoptPaneColor. It turns out that using adoptPaneColor > triggers a > >>>> relayout of the morph, even if it is not visible. We extended > PanelMorph in > >>>> the context of Glamour with a less needy logic. > >>>> > >>>> I will not tell you how fast it is. I would rather want you to play > with > >>>> it :). > >>>> > >>>> The change is already in the Moose image. It is not yet in Pharo, but > it > >>>> will be soon. In the meantime you can be load it in Pharo 6 like this: > >>>> > >>>> Gofer new > >>>> smalltalkhubUser: 'Moose' project: 'GToolkit'; > >>>> package: 'ConfigurationOfGToolkitCore'; > >>>> load. > >>>> (#ConfigurationOfGToolkitCore asClass project version: #stable) > >>>> load > >>>> > >>>> To play with it, try this with both the current version and the new > one > >>>> and the Spec Inspector if you want (just make sure you save the image > >>>> beforehand): > >>>> > >>>> collection := (1 to: 100000000) asArray. > >>>> [collection inspect] timeToRun. > >>>> > >>>> collection := (1 to: 100000000). > >>>> [collection inspect] timeToRun. > >>>> > >>>> (for these two ones notice that Items do not appear at all in the old > >>>> implementation) > >>>> > >>>> [World inspect] timeToRun. > >>>> > >>>> > >>>> There are still a couple of issues open, such as the sorting of the > >>>> columns. We would need your help with testing this, and report > possible > >>>> missing issues. > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> www.feenk.com > >>>> > >>>> "Obvious things are difficult to teach." > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> Using Opera's mail client: http://www.opera.com/mail/ > >>> > >> > > > > >

March 23, 2017

Re: [Pharo-dev] inspector performance improvement

by Henrik Johansen

I guess I'm late to the party, downloaded the latest Moose image today, compared to Pharo5/6, it's night and day! Browsing large collections is quicker than I can ever remember, if emails had emoticons, there'd be a :partyhat: right here, great job! You're probably aware already, but there's an issue with the indexes for the items tab when collections contain the same object multiple times, say o := Object new. oc := OrderedCollection new: 2. 1 to: 2 do: [:i | oc add: o]. oc inspect or ba := (ByteArray new: 20000) inspect. 0 to: 19999 do: [:i | ba at: i + 1 put: i \\ 255 + 1]. ba inspect. Finding a solution that avoids doing indexOf: lookups, but pass along the index instead when needed would be nice ;) The second example also highlight that there seems to be a (legacy?) restriction of 10k entries in the raw view; the list jumps from index 5000 -> 15001, this shouldn't be necessary anymore, right?. *EDIT* After some digging, and testing with a large collection where the limit is raised, I can see why it's there... Find attached some improvements to FT that should (at least act as a PoC that it's possible to) improve performance enough with large trees to possibly remove indexableDisplayLimit entirely. Tested by inspecting a 2M ByteArray, while opening the tab took ~5 secs, navigation/scrolling afterwards was smooth sailing. Cheers, Henry > On 13 Feb 2017, at 11:56 , Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > On Sun, Feb 12, 2017 at 5:07 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> Any chance for this to run on a 5.0? > > There are two main changes: moved inspector to fast table and some > fixes in the glamour renderer. > Moving the changes for the glamour renderer should be straightforward. > I can point you to the list of relevant commits if you want to make a > slice (We'll just need afterwards to also update > ConfigurationOfGlamourCore to still work for Pharo 5) > > The FastTable changes could require more work but that should also be > doable. However, now we still have some issues to fix there so that's > not done for the moment. > > > Cheers, > Andrei > > >> >> Phil >> >> On Sun, Feb 12, 2017 at 3:13 PM, stepharong <stepharong(a)free.fr> wrote: >>> >>> Great job!!!! >>> It feels lot snappier :) >>> Now it is a real pleasure to navigate objects. >>> This is nice to see that you are paying attention because the engine is >>> getting faster and this is important >>> that the tools do not eat all the power by accident. >>> Tx a lot >>> >>> >>> On Sat, 11 Feb 2017 21:31:56 +0100, Tudor Girba <tudor(a)tudorgirba.com> >>> wrote: >>> >>>> Hi, >>>> >>>> Andrei and Alex did a great job at improving the performance and >>>> scalability of the inspector. >>>> >>>> There are a couple of main improvements: >>>> - Added FastTable support for the Raw presentation for all objects. This >>>> implied completing the support for the tree presentation binding to fast >>>> table. >>>> - Moved the Items presentation for collections to FastTable. >>>> - Improved the rendering of Glamour to no longer rely on the default >>>> Morph>>#adoptPaneColor. It turns out that using adoptPaneColor triggers a >>>> relayout of the morph, even if it is not visible. We extended PanelMorph in >>>> the context of Glamour with a less needy logic. >>>> >>>> I will not tell you how fast it is. I would rather want you to play with >>>> it :). >>>> >>>> The change is already in the Moose image. It is not yet in Pharo, but it >>>> will be soon. In the meantime you can be load it in Pharo 6 like this: >>>> >>>> Gofer new >>>> smalltalkhubUser: 'Moose' project: 'GToolkit'; >>>> package: 'ConfigurationOfGToolkitCore'; >>>> load. >>>> (#ConfigurationOfGToolkitCore asClass project version: #stable) >>>> load >>>> >>>> To play with it, try this with both the current version and the new one >>>> and the Spec Inspector if you want (just make sure you save the image >>>> beforehand): >>>> >>>> collection := (1 to: 100000000) asArray. >>>> [collection inspect] timeToRun. >>>> >>>> collection := (1 to: 100000000). >>>> [collection inspect] timeToRun. >>>> >>>> (for these two ones notice that Items do not appear at all in the old >>>> implementation) >>>> >>>> [World inspect] timeToRun. >>>> >>>> >>>> There are still a couple of issues open, such as the sorting of the >>>> columns. We would need your help with testing this, and report possible >>>> missing issues. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Obvious things are difficult to teach." >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Using Opera's mail client: http://www.opera.com/mail/ >>> >> >

March 23, 2017

Re: [Pharo-dev] How to install Iceberg?

by Christophe Demarey

Hi Alex, the master branch is quite old. Please use dev-0.4 branch with the latest stable VM. > Le 26 aoÃ»t 2016 Ã 11:46, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > You should search for it on GitHub :) > > Metacello new > baseline: 'Iceberg'; > repository: 'github://npasserini/iceberg'; > load > > Cheers, > Doru > > >> On Aug 26, 2016, at 11:40 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> Hi all! >> >> I would like to give a try to Iceberg. >> >> I have no idea where to find it however. >> >> Cheers, >> Alexandre >> <Screen Shot 2016-08-26 at 11.39.42 AM.png><Screen Shot 2016-08-26 at 11.40.01 AM.png> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > >

March 23, 2017

Good way to promote Smalltalk

by askoh

Being able to shine in software competitions is a very good way for Smalltalk to get exposure. We should present our technologies as such competitions as much as possible. Enjoy the case below. http://www.cincomsmalltalk.com/main/2017/03/one-cincom-engineer-got-450-pro… Aik-Siong Koh -- View this message in context: http://forum.world.st/Good-way-to-promote-Smalltalk-tp4939758.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 23, 2017

Fwd: GSoC 2017: Tips on Reviewing Student Proposals

by Serge Stinckwich

Dear all, this is a short update for the Google Summer of Code 2017. The students have to submit your proposals on the Google website before April 3rd. See details below. I dunno exactly who are the students/mentors who are submitting a proposal for Pharo. Can the mentors (or students) send me in private an email about the name of the students/mentors + a title of your project ? Thank you very much. Regards, ---------- Forwarded message ---------- From: Google Summer of Code <summerofcode-noreply(a)google.com> Date: Mon, Mar 20, 2017 at 7:26 PM Subject: GSoC 2017: Tips on Reviewing Student Proposals To: sergestinckwich(a)gmail.com [image: Google Summer of Code] Hi Serge Stinckwich, Thank you for registering to be a GSoC 2017 mentor or organization administrator! We have many new mentors and organizations this year so we wanted to go through some important details to help you understand the process for the next couple of months. Please take the time to reach out to your organization administrator about what is expected of you this year as a mentor. We also encourage you to read the entire Google Summer of Code mentor manual <http://write.flossmanuals.net/gsoc-mentoring/about-this-manual/> and the Roles and Responsibilities doc if you haven't done so already. Both the manual and Roles and Responsibilities doc were written by GSoC veteran Org Admins, Mentors, former students and Google Program Admins. They have helpful information about the program and how to participate successfully at each step in GSoC. *New GSoC Orgs*: the section about participating in your first GSoC has some great tips. To see all emails sent to mentors and org admins visit this page <https://developers.google.com/open-source/gsoc/2017/mentor-oa-announcements> that will continue to be updated throughout the program. Student Proposals As of today, students are able to submit their proposals via the website. Each student may submit up to 5 proposals to the program. They can submit multiple proposals to the same organization for different projects if they wish. Historically, the students with the best proposals reach out to the orgs early to receive feedback before submitting their final proposal. To encourage more students to seek feedback on their proposals we made draft proposals part of the official proposal workflow. Be sure to refresh your dashboard periodically so that you can see when new drafts are ready to review. You will not receive an email. We are encouraging the use of Google Docs for proposals as this will allow you to comment directly on the proposal (if the student sets their sharing settings correctly). Over the next couple of weeks you will be interacting with dozens and in some cases hundreds of students interested in working with your project. We know many of you may become overwhelmed and some students can be impatient, so you may want to have an auto-responder or some sort of canned response to let students know you are looking at their proposals but it could take X days to receive a response. Students *must* submit their final proposal as a PDF through the website. It will be visible to you after the deadline for student applications (April 3 16:00 UTC). You should make your decisions on which students to accept based on the contents of the final PDF proposal and your interactions with the student. Students can delete their proposals and you will not receive an email of the deletion. If a proposal disappears from your list, it is likely because they deleted it. Working with Students All student projects must have at least 1 mentor assigned to the project. We strongly encourage assigning a second mentor as a backup mentor or co-mentor. A mentor should not be the primary mentor for more than one or two students. Mentoring can be a lot of work and we donât want anyone to burn out and become frustrated with the program. Important GSoC 2017 Dates and Deadlines *March 20 - April 3 16:00 UTC*: Mentors and Org Admins review student draft proposals and give students feedback on their proposals. *April 3 - 16:* Review all submitted student proposals with your org and consider how many you want to select and how many you can handle. Decide on the minimum/maximum number of student slots to request. *April 17, 16:00 UTC*: Deadline to submit slot requests (OAs enter requests) *April 19, 16:00 UTC*: Slot allocations are announced by Google *April 19 - 24 16:00 UTC* : Select the proposals to become student projects. At least 1 mentor must be assigned to each project before it can be selected. (OAs enter selections) *April 24 - May 4:* Google Program Admins will do another review of student eligibility *May 4*: Accepted GSoC students/projects are announced *May 4 - 29*: Community Bonding Period *May 30*: Coding begins *June 26-30*: First evaluation period - mentors evaluate students, students evaluate mentors *July 24 - 28*: Second evaluation period - mentors evaluate students, students evaluate mentors *August 21- 29*: Students wrap up their projects and submit final evaluation of their mentor *August 29 - September 5*: Mentors submit final evaluations of students *September 6*: Students passing GSoC 2017 are announced Mentors Mailing List If you want to be included on the GSoC mentors mailing list be sure to opt in on your User Profile page. We will add anyone who has opted in to the list every few days for the next month. And then every couple of weeks throughout the program. You can always opt out once you have been added by unsubscribing using the link on any of the emails. Contact Us Please use the gsoc-support(a)google.com email address for questions so that anyone on our team can answer your question for you. We look forward to working with all of you over these next 6 months! Thanks again for being a mentor for GSoC 2017! Google Open Source Programs Office This email was sent to serge.stinckwich(a)gmail.com. You are receiving this email because of your participation in Google Summer of Code 2017. https://summerofcode.withgoogle.com To leave the program and stop receiving all emails, you can go to your profile <https://summerofcode.withgoogle.com/dashboard/profile/> and request deletion of your program profile. For any questions, please contact gsoc-support(a)google.com. Replies to this message go to an unmonitored mailbox. Â© 2017 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

March 23, 2017

Re: [Pharo-dev] More Windows VM Crashing -_-

by Aliaksei Syrel

Hi all, I got a strange crash on Mac, never saw any similar crash dump. Image: 6.0 #60447 5.0 Mac OS X built on Mar 10 2017 13:46:32 UTC Compiler: 4.2.1 Compatible > Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur VM] > CoInterpreter * VMMaker.oscog-eem.2146 uuid: da6aee6e-4738-4161-b221-3c8135ac1bf7 > Mar 10 2017 > StackToRegisterMappingCogit * VMMaker.oscog-eem.2146 uuid: > da6aee6e-4738-4161-b221-3c8135ac1bf7 Mar 10 2017 > VM: 201703101242 https://github.com/pharo-project/pharo-vm.git $ Date: > Fri Mar 10 13:42:34 2017 +0100 $ > Plugins: 201703101242 https://github.com/pharo-project/pharo-vm.git $ First few lines of crash (the whole dump is in attachment): C stack backtrace & registers: eax 0x849671d0 ebx 0x7c6e3820 ecx 0x90301065 edx 0xe0000000 edi 0x7c6e3820 esi 0x7c6e3820 ebp 0xbff40708 esp 0xbff404c8 eip 0x9ef29013 0 libobjc.A.dylib 0x9ef29013 objc_msgSend + 19 1 Pharo 0x0010227a reportStackState + 706 2 Pharo 0x001025d2 sigsegv + 113 3 libsystem_platform.dylib 0x9f98bebb _sigtramp + 43 4 ??? 0xffffffff 0x0 + 4294967295 5 CoreFoundation 0x94671888 _CFAutoreleasePoolPop + 24 6 HIToolbox 0x9401fa35 IMKInputSessionProcessEventRefWithCompletionHandler + 125 7 HIToolbox 0x9401ebd2 InputMethodInstanceProcessEventRef_WithCompletionHandler + 135 8 HIToolbox 0x94006c9c __TSMEventToInputMethod_ WithCompletionHandler_block_invoke + 121 9 HIToolbox 0x9400b3fa __TrySendLockEvent_ BeforeEventToInputMethod_WithContinuationHandler_block_invoke + 27 10 HIToolbox 0x9400b496 __SendTSMDocumentLockEvent_WithCompletionHandler_block_invoke + 90 11 HIToolbox 0x93ddc6a3 __SendTSMEvent_ WithCompletionHandler_block_invoke + 66 12 HIToolbox 0x93ddf651 __ SendEventToEventTargetWithCompletionHandler_block_invoke + 22 Cheers, Alex On 22 March 2017 at 21:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I do not think this is a windows problem. > At least, I had some crashes when performing compaction last days tooâ¦ > this is a crash I collected 10 mins ago, in a mac. > > cheers, > Esteban > > > > > > On 22 Mar 2017, at 10:31, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > Originally I thought my VM is crashing because of FT, so I applied some > fix from FogBugz (that is now part of Pharo 6), but that didn't help. > > > > So I disabled FT in settings and changed fonts to non-FT ones; didn't > help. > > So I completely removed FT2Plugin.dll (now settings just states that FT > fonts are not available), but that didn't help either. > > > > And obviously there is no crash.dmp whatsoever (this is latest Windows > VM). > > > > This crash is extremely frustrating because the crash happens _during > saving_, which means I am losing code all the time and have to constantly > recover them, which really makes my blood boil. > > > > Without crash dump I don't even know where and how to start > investigating. Windows kindly opens Visual Studio when Pharo crashes, but > all it shows to me is assembly, which is not very useful to me. I can > somewhat orient myself in the C code of the VM (as I've alredy fixed some > other issues in the VM), but here I am lost. > > > > <SNIP> > > 00407D7F ret > > 00407D80 mov eax,dword ptr ds:[00596E44h] > > 00407D85 test al,3 > > 00407D87 jne 00407DB2 > > 00407D89 mov ecx,dword ptr ds:[596E08h] > > 00407D8F lea edx,[ecx-1] > > 00407D92 cmp eax,edx > > 00407D94 jb 00407DB2 > > 00407D96 cmp dword ptr ds:[596E10h],eax > > 00407D9C jb 00407DB2 > > 00407D9E mov ecx,dword ptr ds:[5B89D0h] > > 00407DA4 cmp dword ptr [eax-4],ecx > > 00407DA7 jb 00407DB2 > > 00407DA9 mov eax,dword ptr ds:[00596E28h] > > ---> 00407DAE movzx eax,byte ptr [eax] > > 00407DB1 ret > > > > eax = 00000000 > > ecx = 04700000 > > </SNIP> > > > > So my question I guess is: > > How can we fix this? How can I help fix this? Because I've lost > countless days of time and energy on this f***ing problem... > > > > Peter > > > > >

March 23, 2017