We could try reverting only those changes from the latest PharoVM code, build the VM ourselves and try again. I’d do it but I’m out of time at the moment. Eliot, is revision 2640 available in any git repository? That might make cherry picking / reverting easier (at least for me it would :) ) |
On Fri, Mar 28, 2014 at 1:44 AM, Max Leske <[hidden email]> wrote:
It's in svn, but that's not the right way to integrate. Since the fixes are Smalltalk code the right way is to integrate in Monticello and generate a new VM.
<rant>But of course Pharo decided that git integration was more important than working on a perfectly good distributed version control system and now there is no easy way to move Smalltalk changes between Monticello and Monticello+git. I'm unhappy about that. But it's not my problem. Anyone wanting to send changes back to me can either publish in Monticello or send me file-outs, etc, etc. Anybody wanting my code can get it from http://source.squeak.org/VMMaker via Monticello. Why the community would rather put up barriers to talking to each other so that it can attract the uninterested rest of the world is over my head. I'm concentrating on Spur, which I hope will be useful to everyone in the community.</rant>
best, Eliot
|
On 28-03-2014, at 10:55 AM, Eliot Miranda <[hidden email]> wrote: > <rant>But of course Pharo decided that git integration was more important than working on a perfectly good distributed version control system and now there is no easy way to move Smalltalk changes between Monticello and Monticello+git. I'm unhappy about that. But it's not my problem. Anyone wanting to send changes back to me can either publish in Monticello or send me file-outs, etc, etc. Anybody wanting my code can get it from http://source.squeak.org/VMMaker via Monticello. Why the community would rather put up barriers to talking to each other so that it can attract the uninterested rest of the world is over my head. I'm concentrating on Spur, which I hope will be useful to everyone in the community.</rant> > Hear-hear. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: DMK: Destroy Memory-protection Key |
On 28 Mar 2014, at 16:10, tim Rowledge <[hidden email]> wrote: > > > On 28-03-2014, at 10:55 AM, Eliot Miranda <[hidden email]> wrote: > >> <rant>But of course Pharo decided that git integration was more important than working on a perfectly good distributed version control system and now there is no easy way to move Smalltalk changes between Monticello and Monticello+git. I'm unhappy about that. But it's not my problem. Anyone wanting to send changes back to me can either publish in Monticello or send me file-outs, etc, etc. Anybody wanting my code can get it from http://source.squeak.org/VMMaker via Monticello. Why the community would rather put up barriers to talking to each other so that it can attract the uninterested rest of the world is over my head. I'm concentrating on Spur, which I hope will be useful to everyone in the community.</rant> well… I understand your frustration. But I promised you (and I meant to accomplish) that I was going to prepare a job who pushes back the monticello packages so they are available. Sadly with all the running for releasing pharo3 I didn’t find the time yet… but next month I will have a few more time (just when I came back from my vacations). Esteban >> > > Hear-hear. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: DMK: Destroy Memory-protection Key > > |
On Fri, Mar 28, 2014 at 12:38 PM, Esteban Lorenzano <[hidden email]> wrote: --
thanks Esteban, that will be _much_ appreciated!!
best, Eliot
|
While we are at ranting... Even if you go thru the first tool hurdle (loading filetree in image and cloning a git repo is not that high), there's another concern: a lot of changes in the pharo-vm branch are purely aesthetical: - a space has been added here and there - or just the author changed...I'd like to help Pharo, but please, help us to help you 2014-03-28 22:11 GMT+01:00 Eliot Miranda <[hidden email]>:
|
In reply to this post by Max Leske
Loading in a Moose image VMMaker.oscog-eem.240.mcz VMMaker.oscog-eem.236.mcz VMMaker-oscog-LaurentLaffont.303.mcz There are 12 methods that changed from 236 to 240 that are not the same in 303 (ignoring removed methods): StackInterpreter>findClassOfMethod:forReceiver: StackInterpreter>floatValueOf: ObjectMemory>changeClassOf:to: Cogit>declareCVarsIn: StackInterpreter>isLiveContext: InterpreterPrimitives>isInstanceOfClassByteString: StackInterpreter>longPrintoop: NewObjectMemory>okayOop: NewObjectMemory>incrementalGC: Stephan |
2014-04-02 11:42 GMT+02:00 Stephan Eggermont <[hidden email]>:
Hmm, don't waste too much time. All these methods are unchanged in github pharo-vm head revision (VMMaker-oscog-StefanMarr.313) The cause must be completely different in latest pharo vms. There are way too many changes to analyze if you want to diff with VMMaker.oscog branch - changes related to using FileSystem instead of FileDirectory - changes related to ephemerons - changes related to NB - ... ? - many many false changes ( just formatting of methods - please don't do that! ) The right way to debug this is to have a VMSimulator working and be patient... |
In reply to this post by Max Leske
Nicolas wrote: >Hmm, don't waste too much time. >All these methods are unchanged in github pharo-vm head revision (VMMaker-oscog-StefanMarr.313) >The cause must be completely different in latest pharo vms. Uhm, why? They haven’t changed. Pharo vms 105 and later no longer crash, but all reliably show the bug. And 236 is the last Squeak one to show the problem. I might take a look at Esteban’s versions from the same time, 228 and 229 Stephan |
2014-04-02 23:59 GMT+02:00 Stephan Eggermont <[hidden email]>:
Sorry, haven't changed means that there's no diff with the corrected version. IOW, the fixes from Eliot have been integrated for a long time already. You are seeing another symptom, probably another bug impacting the same code. There are many diffs between pharo's and Eliot's branch, but not where you're looking at. Pharo vms 105 and later no longer crash, but all reliably show the bug. |
Good news, I've managed to make your issue apparently vanish in Pharo3.0 VM.- cleaned up unecessary differences with Eliot's VMMaker.oscog branch, - removed unecessary changes ahead of VMMaker.oscog-eem.333 version (those stamped LucFabresse) - integrated the issues for which I emitted a pull request All this work can be found publicly at https://github.com/nicolas-cellier-aka-nice/pharo-vm/compare/fixMergeWithEliotVersion333
I cannot tell which missing change exactly was the root cause, and I cannot dissect either, but I saw several + LiteralStart missing... Or it could be related to cogit method/block native code generation... The changes are most probably here https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/af718618eee516d15c0b362123e3a77c8b6fd2e8 2014-04-03 4:13 GMT+02:00 Nicolas Cellier <[hidden email]>:
|
2014-04-06 22:29 GMT+02:00 Nicolas Cellier <[hidden email]>:
Haha! this is Class class>>superclassOrder: which break things... The order of structures passed on input was mostly good but ruined on output...
The Squeak ChangeSet class>>superclassOrder: does not convert the list of classes asSet, thus somehow preserves provided order. The Pharo version does not take so much care it seems... Apparently the method was changed again in Pharo3.0, but neither does it preserve order. After fixing it, compilation went well...
|
In reply to this post by Max Leske
(Nicolas, do you use fogbugz?) Igor wrote on the issue tracker: c631221ce2fe993c611dc7bced0d50876a3928c5 and after fixing #superClassOrder: (by simply removing a call to it), ive managed to build VM. However this code still fails: 1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ]. (you need Transcript window open for it to fail) Edited by Igor Stasenko 4/11/2014 (Today) 4:29 PM -- built a debug version of VM, reveals no assertions, nothing |
Hi Stephan, What happens if you use "-cogminjumps 10000" on the command line? This flag determines how many times an interpreted method needs to loop for the VM to decide to convert the interpreted activation containing the loop into a machine-code activation. If there is a bug in bytecode-to-machine-code pc mapping the VM can crash. I wonder whether that could be the issue here.
On Fri, Apr 11, 2014 at 11:43 AM, Stephan Eggermont <[hidden email]> wrote:
best, Eliot
|
In reply to this post by Stephan Eggermont-3
2014-04-11 20:43 GMT+02:00 Stephan Eggermont <[hidden email]>:
Ahem... This works on my mac at least. Transcript opened or not, the iterations always go to the 1000th without MessageNotUnderstood |
2014-04-11 23:29 GMT+02:00 Nicolas Cellier <[hidden email]>: I forgot to answer: YES, I use fogbugz, and I starred this issue. But for some reason, the only things I regularly see coming in my inbox are those automated Monkey editions. Either I mechanically removed a human edition in a flow of monkeys, or I did not receive anything human...
|
2014-04-11 23:43 GMT+02:00 Nicolas Cellier <[hidden email]>:
For those not in fogbugz, It works on my mac not because I applied the delta with Eliot's branch... But because I have an older compiler: I'm on MacOsX 10.6.8 with Xcode Version 3.2.6 and i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) |
In reply to this post by Max Leske
Nicolas wrote >YES, I use fogbugz, and I starred this issue. >But for some reason, the only things I regularly see coming in my inbox are those automated Monkey editions. >Either I mechanically removed a human edition in a flow of monkeys, or I did not receive anything human… Known issue with Fogbugz, I’m afraid. Monkey has a separate flow. To get notified of non-monkey changes, you need to add yourself to the subscriber list. I added you to the list. Stephan p.s. Eliot, you are not subscribed |
In reply to this post by Nicolas Cellier
Nicolas Cellier wrote: Just fyi since it caught me out. Starring the issue is not subscribing to it. That is beneath the sidebar. cheers -ben |
Free forum by Nabble | Edit this page |