VM Maker: VMMaker.oscog-nice.1733.mcz
Locked
 
|
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz ==================== Summary ==================== Name: VMMaker.oscog-nice.1733 Author: nice Time: 17 March 2016, 11:45:52.436 pm UUID: cc4513ea-67e5-4b41-b7bd-2fc790ac0102 Ancestors: VMMaker.oscog-nice.1732 Oups (Oops) forgot the <doNotGenerate> for simulated #stSizeOf: version. =============== Diff against VMMaker.oscog-nice.1732 =============== Item was changed: ----- Method: SpurMemoryManager>>stSizeOf: (in category 'object access') ----- stSizeOf: oop "Return the number of indexable fields in the receiver" + <doNotGenerate> ^oop basicSize! |
|
|
Hi Nico, somewhere between this and VMMaker.oscog-dtl.1730 all PharoVMs become unusable :( are you aware of this? maybe I’m forgetting something in my builds? cheers, Esteban > On 17 Mar 2016, at 22:49, [hidden email] wrote: > > > Nicolas Cellier uploaded a new version of VMMaker to project VM Maker: > http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz > > ==================== Summary ==================== > > Name: VMMaker.oscog-nice.1733 > Author: nice > Time: 17 March 2016, 11:45:52.436 pm > UUID: cc4513ea-67e5-4b41-b7bd-2fc790ac0102 > Ancestors: VMMaker.oscog-nice.1732 > > Oups (Oops) forgot the <doNotGenerate> for simulated #stSizeOf: version. > > =============== Diff against VMMaker.oscog-nice.1732 =============== > > Item was changed: > ----- Method: SpurMemoryManager>>stSizeOf: (in category 'object access') ----- > stSizeOf: oop > "Return the number of indexable fields in the receiver" > + <doNotGenerate> > ^oop basicSize! > |
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
2016-03-18 16:00 GMT+01:00 Esteban Lorenzano <[hidden email]>:
Hi Esteban, Please provide more feedback - can/can't compile ? - VM crash ? instantly or on specific operations ? - all OS or OS specific ? - which flavour - stack/cogit x spur/v3 x 32/64 bits ? I presume cogit-spur-32bits for Pharo head? Maybe a few explanations accompanying a Jenkins link would do it I've experimented macosx stack spur 64 bits with simulator, and I use most of these changes in my own VM branch, except the fetch64/store64 message sends I'll check ASAP (this will be tonight) Nicolas > On 17 Mar 2016, at 22:49, [hidden email] wrote: |
|
|
can compile, but image is unusable (no refresh of UI… error with Bitmaps I think).
all environments (mac, linux and win) have this problem.
yes
I don’t know what more to say :) but if you download: wget -O- get.pharo.org/50+vmLatest | bash and execute it… you will see the problem. and that does not happens if you execute wget -O- get.pharo.org/50+vm | bash (the only difference between those VMs are your commits). cheers, Esteban
|
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
Hi Esteban,
1. build an assert-enabled VM and run this. You may get very useful error information. You can use the -trace flag to get it to output the sends the VM makes and see where the first error is 2. Open the image in the simulator, but that may be difficult with pharo cuz it uses so many external libraries. Nite that you can still, with a little effort, do this but you have to write the plugin simulation code that maps from calls in the simulator to calls against the host VM's facilities. For example, in the simulator the FilePluginSimulator defers to the host Smalltalk system to access files so the simulated VM can still access files just like the real VM, which defers to the stdio library or win32 APIs to access files. The simulator is not just worth maintaining it is /essential/ to being able to debug the VM effectively. It should be a goal to have the Pharo image runnable in the simulator.
|
|
|
no, today I’m not there :)
that’s the first thing I did… it does not says anything :( The only information I have is a stack trace: Bitmap(Object)>>error: Bitmap(Object)>>errorImproperStore Bitmap(Object)>>at:put: Bitmap class(ArrayedCollection class)>>with: Color>>bitPatternForDepth: Form>>bitPatternFor: BitBlt>>fillColor: BitBlt>>setDestForm:sourceForm:fillColor:combinationRule:destOrigin:sourceOrigin:extent:clipRect: BitBlt class>>destForm:sourceForm:fillColor:combinationRule:destOrigin:sourceOrigin:extent:clipRect: Form(DisplayMedium)>>fillShape:fillColor:at: Form(DisplayMedium)>>fillShape:fillColor: CursorWithMask>>asCursorForm HandMorph>>showTemporaryCursor:hotSpotOffset: HandMorph>>showTemporaryCursor: RubEditingArea(RubAbstractTextArea)>>showOverEditableTextCursor RubEditingArea(RubAbstractTextArea)>>mouseEnter: RubEditingArea(Morph)>>handleMouseEnter: MouseMoveEvent(MouseEvent)>>sentTo: MouseMoveEvent>>sentTo: RubEditingArea(Morph)>>handleEvent: MouseOverHandler>>transform:from:andSendTo: [ self transform: evt from: anEvent andSendTo: aLeftMorph ] in MouseOverHandler>>inform:to:originatedFrom:ifNotFocusedDo: in Block: [ self transform: evt from: anEvent andSendTo: aLe...etc... True>>ifTrue:ifFalse: MouseOverHandler>>inform:to:originatedFrom:ifNotFocusedDo: [ :anEnteredMorph | self inform: asMouseEnterEvent to: anEnteredMorph originatedFrom: anEvent ifNotFocusedDo: [ ] ] in MouseOverHandler>>handleAsMouseEnter: in Block: [ :anEnteredMorph | ... Array(SequenceableCollection)>>reverseDo: MouseOverHandler>>handleAsMouseEnter: MouseOverHandler>>processMouseOver: HandMorph>>handleEvent: HandMorph>>processEvents cheers, Esteban
|
|
|
In reply to this post by Eliot Miranda-2
btw… that means it works ok in your VMs? I would be very surprised, since error seems to happen in places I never seen before (which usually means we didn’t change anything there). Esteban
|
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
In reply to this post by EstebanLM
Hi Esteban,
On Fri, Mar 18, 2016 at 9:27 AM, Esteban Lorenzano <[hidden email]> wrote:
Now get a C backtrace and see if the VM is in the interpreter or if in machine code. If in interpreter walk up the C stack until you're in the function interpret then use "call shortPrintFrameAndCallers(localFP)" to get the backtrace of frames. If this fails, rerun using a debug VM (localFP may be optimised and so it may work only in the unoptimised debug VM). If not in the interpreter (there will be some weird call stack pointing back into form frame that won't have a name, but just an address), use "call printStackCallStack()" to get the backtrace. Now, once you have located the frame for Bitmap(Object)>>at:put:, use "call printFrame(TheFramePointerValue)" to print the frame in detail, including arguments, temporaries and stack contents, etc. That should show you what the argument is and whether there's a bug in Bitmap>>at:put; or some other bug. You can print the sender frame by using the "saved fp" value. You should be able to narrow down that cause a lot using these functions. It's not a patch on the Smalltalk debugger; it's slow and error prone, but you can debug images that won't start. It's much easier in the simulator, but possible in gdb/lldb. Good luck!
_,,,^..^,,,_ best, Eliot |
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
Esteban I confirm that this happens on 32bits squeak.stack.spur too.2016-03-18 20:46 GMT+01:00 Eliot Miranda <[hidden email]>:
|
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
Ah got it in http://smalltalkhub.com/mc/nice/NiceVMExperiments/main But the diff did not help, I must track further-------------------------------------- Name: VMMaker.oscog-nice.1515 Author: nice Time: 9 November 2015, 12:16:42.195 am UUID: 120aa03b-9686-4219-bd35-0e90011f64be Ancestors: VMMaker.oscog-nice.1514 Fix spurious signed/unsigned BUG I reintroduced by restoring Eliot's positive32BitIntegerFor: version The main symptom is Bitmap improper store... ...due to (65536 bitOr: (65536 bitShift: 16)) answering -1... -------------------------------------- 2016-03-18 21:07 GMT+01:00 Nicolas Cellier <[hidden email]>:
|
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
In reply to this post by Eliot Miranda-2
I wonder why you do not check our builds before pushing a change. Staging changes can make sure that we control the propagation of errors. And as you know, error = time = money. This is always difficult for someone to try to understand error that he had no clue from where they come. Stef |
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
Stephane, that's my fault and I apologize.This time, i've not put enough effort before the commit. Instead i've put excessive confidence in the simulator and my previous work in own branch. I can only commit nightly, so effectively, it can cost a day before I correct my mistakes. HOWEVER, may I remind you the combinatorial:(spur,v3) x (interpreter,cogit) x (32,64bits) x (mac,win,linux,...) x (squeak,pharo,newspeak) not speaking of ARM, android free bsd etc... You naturally put YOUR build above every other, but to me this has no more value than anyone else bias. The commiter should be notified, and that was the case. So what do you want more? Everyone else duplicating this effort? Ggit would help managing development with branches, but we are not there currently, so please revise your standards. You know that I'm not found of the break it first, fix it later strategy. Though it sometimes happen that I get caught. Here it sounds like you are not granting to me this right to break things when in the same time this right is totally abused in every day Pharo development... So despite the fact that you are completely right this time, I'd say that I would have been more inclined to take the lesson I deserved from say Eliot ;) Stephane, I like your energy, and I wish I could use and promote Pharo, but please, keep it positive :) Tonight, you gave me bad vibrations :( Nicolas 2016-03-18 22:13 GMT+01:00 stephane ducasse <[hidden email]>:
|
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
I paid igor during six months to have this infrastructure and people can take it and run away with it and use it for there own needs. And instead of taking advantages we got “oh this is for pharo”. With clement we are checking the kind of slaves we can put in place to tests his crazy tests. Because against combinatorial there is machines and automated process.
Esteban is managing all with git just because this is easier and empowering us. Moving a project to git is not that a big deal. I hate git API personnally but I imagine that git should not be a problem for people mastering VM. So I do not see the point. The problem here is not technological. But again we are free not to use the tools that can empower us. But then in that case why using VMmaker and not plain C. You see this is the same argument.
This is not a question of lesson taken this is a economical point. Within a year esteban will leave in another place and have its own company and run for money and the question is should he spent time trying to understand and fix things that a simple farm of machine could have caught?
since this is perfect.
|
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
In reply to this post by Nicolas Cellier
Two points
I have problem that automated tests do not catch it to free programmers and brain.
For example this year we did not integrate Epicea and marcus tried 15 times (for real 15 times) this is just that you did not see it. Now we break things because we do not have enough tests and UI/widgets is not covered.
|
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
In reply to this post by Nicolas Cellier
> On 19 Mar 2016, at 01:23, Nicolas Cellier <[hidden email]> wrote: Dear Nicolas, > Stephane, that's my fault and I apologize.This time, i've not put enough effort before the commit. > Instead i've put excessive confidence in the simulator and my previous work in own branch. > I can only commit nightly, so effectively, it can cost a day before I correct my mistakes. > > HOWEVER, may I remind you the combinatorial: > (spur,v3) x (interpreter,cogit) x (32,64bits) x (mac,win,linux,...) x (squeak,pharo,newspeak) > not speaking of ARM, android free bsd etc... > How do you conceivably expect that a single contributor like me would perform tests for each and every configuration? the burden should never be on a single contributor but luckily computing time has become so cheap that many projects let computers take care of it (nobody needs to wait for a batch job, nobody needs hours to wait for a compiler, etc). Specially with github and travis-ci (or semaphoreci, wercker, ... or tons of other services) it becomes very easy to execute a matrix of configurations before merging something to master. This includes running tests on Linux and OSX and maybe on the Android emaulator if you want to. Before working on Telecommunication I was a WebKit reviewer and we had a strict policy on regressions. No user should experience an issue that has been already resolved once. This leads to a policy where bug fixes come with tests[1]. I would be very happy if the VM development community could pick-up similar policies. I am happy to help with travis-ci integration. have a nice weekend holger [1] https://webkit.org/contributing-code/#regression-tests |
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
In reply to this post by stephane ducasse-2
Hi Stephane, let's be clear: which tests are you speaking of?- running the simulator is pretty long, it's efficient if you want to focus on a specific bug, less for wide-range testing My goal was to see if I would not break the simulator because Eliot heavily rely on it. I did mainly simulate one flavour : squeak stack spur 64bits. Maybe the 32 bits too, but I'm not sure now- the simulator does not catch all, and have subtle differences about signed/unsigned handling The next level is to generate the code and compile it. I generated these ones: 32bits squeak.cog.v3 squeak.cog.spur squeak.stack.v3 squeak.stack.spur 64bits squeak.cog.spur squeak.stack.spur Then I compiled... It took me a bunch of efforts because the motion of UUIDplugin from internal to external made the compilation failed, I don't know exactly why, so Ias workaround had to first undo it, find . -name '*.o' -delete, then compile again. At this time, I think it was late and I only checked the 64 bits squeak stack spur which fits my main working image. I ran a few tests that passed so I commited these changes that are two years old and that I was preparing for several days. My mistake was to not run a 32 bits image, that's pretty true I messed up. I apologize again. But you can't say that I don't test, it's insulting. I do pretty much for one not being paid to. For these reasons, I invite you to be a bit more forgiving. What I tell you is that a bot DOES the rest of the tests for us. What I tell you is that there is no other way to fire the bot than committing currently. It's not perfect, but that's already something. So what's the point of blaming me for an architecture that I'm not in charge of, that I did not decide, that I don't control? Do you still think I could do more? It's sad that the work of Igor was not leveraged, but it's a social problem not a technical one. Igor work was constructed as a fork. Surprisingly that failed. Or wasn't it doomed to fail because you didn't have the manpower/money/experienced team, whatever the tremendous quality of Igor? Who did take care of the main VM contributor and his own constraints at this time?Please stop saying other do not understand, it's absolutely un-constructive. If you want to see some progress, there's another attitude than being aggressive. You could try to collaborate for example.Do you really want a better infrastucture, git, etc? If yes, then find a win-win attitude with Eliot, and we'll see some progress. Others like me will follow. Can you understand that? 2016-03-19 7:48 GMT+01:00 stephane ducasse <[hidden email]>:
|
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
In reply to this post by stephane ducasse-2
Hi Stef, > On Mar 18, 2016, at 2:13 PM, stephane ducasse <[hidden email]> wrote: > > > I wonder why you do not check our builds before pushing a change. Staging changes can make sure that > we control the propagation of errors. And as you know, error = time = money. > This is always difficult for someone to try to understand error that he had no clue from where they come. We need to stage on the other side. Indeed VMMaker.oscog commits /should/ be expected to break slave builds. Then only VMs that pass slave builds should be put somewhere where non-VM developers can fetch them and rely on them. In my own site I provide a /latest and a /stable link instead of the raw builds. Hopefully the Pharo VM access can be made similar? > > Stef |
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
In reply to this post by stephane ducasse-2
|
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
>> >> I paid igor during six months to have this infrastructure and people can take it and run away with it and use it for there own needs. >> And instead of taking advantages we got “oh this is for pharo”. With clement we are checking the kind of slaves we can put in place to >> tests his crazy tests. Because against combinatorial there is machines and automated process. > > but you never thought to have Igor consult me and come up with a build structure is be happy with. And I'm not happy with the VM infrastructure in the Pharo build and I hope that we can agree on a single build infrastructure, which clearly separates C VM generation from C VM compilation. well I’m not sure that we should reopen such period because I do not think that we are the bad guys in the story. |
Re: VM Maker: VMMaker.oscog-nice.1733.mcz
|
|
In reply to this post by Eliot Miranda-2
> On 19 Mar 2016, at 19:13, Eliot Miranda <[hidden email]> wrote: > > > Hi Stef, > >> On Mar 18, 2016, at 2:13 PM, stephane ducasse <[hidden email]> wrote: >> >> >> I wonder why you do not check our builds before pushing a change. Staging changes can make sure that >> we control the propagation of errors. And as you know, error = time = money. >> This is always difficult for someone to try to understand error that he had no clue from where they come. > > > We need to stage on the other side. Indeed VMMaker.oscog commits /should/ be expected to break slave builds. Then only VMs that pass slave builds should be put somewhere where non-VM developers can fetch them and rely on them. This is not the point again. I’m sorry to be dense: We did publish the changes of this VM. We do not publish changes blindly. Why do you think that we are that stupid? Esteban just mentioned that the changes did not work. And to me this opens a big warning! A tool infrastrcuture should spot that problem not a human. Now apparently you do not believe in such infrastructure. Ok point taken but do not expect that will come to help. I thought that after the years you understand our motivations but apparently not and I cannot do much about it I’m just sad but I’m currently learning many lessons. Stef > > In my own site I provide a /latest and a /stable link instead of the raw builds. Hopefully the Pharo VM access can be made similar? > >> >> Stef |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |