Hi, With DrGeo built on image Pharo7.0-64bit-e41f921 Athens error shows up on the canvas (screenshot). The drgeo dev. environment based on the older Pharo7.0-64bit-f82fc36 image does not have this error with the same VM. The DrGeo build removes some pharo package but it is unlikely to produce such error, or so? -- Dr. Geo http://drgeo.eu
i think it will help more if you reveal the full stack trace with actual exception.. IIRC you can do it by clicking on errorneous morph and in its menu pick the stack trace. On 16 December 2017 at 23:29, Hilaire <hilaire@drgeo.eu> wrote:
Hi,
With DrGeo built on image Pharo7.0-64bit-e41f921 Athens error shows up on the canvas (screenshot).
The drgeo dev. environment based on the older Pharo7.0-64bit-f82fc36 image does not have this error with the same VM.
The DrGeo build removes some pharo package but it is unlikely to produce such error, or so?
-- Dr. Geo http://drgeo.eu
-- Best regards, Igor Stasenko.
Strangely when this morph menu is asked, the same error shows up, see screenshot. May be something else is wrong in the image, in the next days I will try to build differently the image application Le 17/12/2017 à 18:29, Igor Stasenko a écrit :
i think it will help more if you reveal the full stack trace with actual exception.. IIRC you can do it by clicking on errorneous morph and in its menu pick the stack trace.
-- Dr. Geo http://drgeo.eu
Sadly building the image with a light cleaning, does not grant me access to the morph menu of the faulty canvas. Still same error as mentionned in previous screenshot. The upper moprh menu can be access, but there is stack trace entry in its menu (see screesshot). In the following day will try with another image... Le 17/12/2017 à 20:55, Hilaire a écrit :
May be something else is wrong in the image, in the next days I will try to build differently the image application
-- Dr. Geo http://drgeo.eu
Tried to build DrGeo app witht the same image used for development. Still gets red screen of depth on the DrGeo canvas, but with a different error (screenshot for the curious). Image cleaning were removed, so nothing wrong comes from there. Now, if I copied along the image file Pharo7.0-32bit-f82fc36.source. Canvas does not get bogus. What the f*k. Image and VM are 64bits Pharo is really funny Le 18/12/2017 à 21:35, Hilaire a écrit :
In the following day will try with another image...
-- Dr. Geo http://drgeo.eu
Normally the call does not need the sources (if I'm correct in the past it needed to generate the correct method argument or something like that). Can you provide more information? or the image somewhere? Because FFI should improve and we are looking for edge corner bugs. Stef On Wed, Dec 20, 2017 at 8:58 PM, Hilaire <hilaire@drgeo.eu> wrote:
Tried to build DrGeo app witht the same image used for development. Still gets red screen of depth on the DrGeo canvas, but with a different error (screenshot for the curious). Image cleaning were removed, so nothing wrong comes from there.
Now, if I copied along the image file Pharo7.0-32bit-f82fc36.source. Canvas does not get bogus. What the f*k. Image and VM are 64bits
Pharo is really funny
Le 18/12/2017 à 21:35, Hilaire a écrit :
In the following day will try with another image...
-- Dr. Geo http://drgeo.eu
The source is really needed to get Athens functionning, otherwise there is an error. On top of that, the source file name is confused by Pharo (it should be mimic of the 32bits images, althought 64bits image is used, and it should not depend on the bits number I guess). Here is an archive with the image[1], go in Contents/Resources/drgeo.image and used a 64 bits VM to run the image, do not used the embedded VMs, there are for P3. [1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0 Hilaire Le 20/12/2017 à 21:08, Stephane Ducasse a écrit :
Normally the call does not need the sources (if I'm correct in the past it needed to generate the correct method argument or something like that). Can you provide more information? or the image somewhere? Because FFI should improve and we are looking for edge corner bugs.
Stef
-- Dr. Geo http://drgeo.eu
Hi Hilaire your P7 image is older and has problems with FreeType fonts initialization that should be fixed in the newest builds. Maybe that is cause of the Athens issues you are facing. Please upgrade. -- Pavel 2017-12-25 12:05 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
The source is really needed to get Athens functionning, otherwise there is an error. On top of that, the source file name is confused by Pharo (it should be mimic of the 32bits images, althought 64bits image is used, and it should not depend on the bits number I guess).
Here is an archive with the image[1], go in Contents/Resources/drgeo.image and used a 64 bits VM to run the image, do not used the embedded VMs, there are for P3.
[1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0
Hilaire
Le 20/12/2017 à 21:08, Stephane Ducasse a écrit :
Normally the call does not need the sources (if I'm correct in the past it needed to generate the correct method argument or something like that). Can you provide more information? or the image somewhere? Because FFI should improve and we are looking for edge corner bugs.
Stef
-- Dr. Geo http://drgeo.eu
Just make a drgeo build with latest image as of today, the problem is the same with latest image, as long as the source file is not present. Here is the newest built[1] Hilaire [1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0 Le 26/12/2017 à 11:15, Pavel Krivanek a écrit :
Hi Hilaire
your P7 image is older and has problems with FreeType fonts initialization that should be fixed in the newest builds. Maybe that is cause of the Athens issues you are facing. Please upgrade.
-- Dr. Geo http://drgeo.eu
Running your drgeo.image on a recent linux pharo 64 bit vm gives this error message first: /home/nicolai/devel/pharo/Pharo7.0-32bit-52a28a8.sources. With pharo 7, every (bootstrapped)image needs its own sources file? 2017-12-26 11:59 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Just make a drgeo build with latest image as of today, the problem is the same with latest image, as long as the source file is not present. Here is the newest built[1]
Hilaire
[1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0
Le 26/12/2017 à 11:15, Pavel Krivanek a écrit :
Hi Hilaire
your P7 image is older and has problems with FreeType fonts initialization that should be fixed in the newest builds. Maybe that is cause of the Athens issues you are facing. Please upgrade.
-- Dr. Geo http://drgeo.eu
2017-12-26 14:32 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
Running your drgeo.image on a recent linux pharo 64 bit vm gives this error message first:
/home/nicolai/devel/pharo/Pharo7.0-32bit-52a28a8.sources.
With pharo 7, every (bootstrapped)image needs its own sources file?
Every Pharo 7 build creates own sources file but this sources file can be shared between several images based on this build. So for final Pharo 7 we may release one sources file but I doubt that we will do it. During bootstrap all code is loaded into the image as new code so at the end you have empty sources file and huge changes file. We condense such changes file and transform it into sources file so you have empty changes. But we would like have sources directly in the image in compressed form. -- Pavel
2017-12-26 11:59 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Just make a drgeo build with latest image as of today, the problem is the same with latest image, as long as the source file is not present. Here is the newest built[1]
Hilaire
[1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0
Le 26/12/2017 à 11:15, Pavel Krivanek a écrit :
Hi Hilaire
your P7 image is older and has problems with FreeType fonts initialization that should be fixed in the newest builds. Maybe that is cause of the Athens issues you are facing. Please upgrade.
-- Dr. Geo http://drgeo.eu
Hilaire debug drawing error should give you access to the debugger and after you can get the stack. On Mon, Dec 18, 2017 at 9:35 PM, Hilaire <hilaire@drgeo.eu> wrote:
Sadly building the image with a light cleaning, does not grant me access to the morph menu of the faulty canvas. Still same error as mentionned in previous screenshot.
The upper moprh menu can be access, but there is stack trace entry in its menu (see screesshot).
In the following day will try with another image...
Le 17/12/2017 à 20:55, Hilaire a écrit :
May be something else is wrong in the image, in the next days I will try to build differently the image application
-- Dr. Geo http://drgeo.eu
Le 20/12/2017 à 21:05, Stephane Ducasse a écrit :
Hilaire
debug drawing error should give you access to the debugger and after you can get the stack.
Like this ? FFICallout>>loaderForArgNamed: FFICallout>>loaderForArgNamed:indirectIndex: FFICallout>>argName:indirectIndex:type:ptrArity: FFIFunctionParser>>parseArgument FFIFunctionParser>>parseArguments FFIFunctionParser>>parseNamedFunction: FFICalloutMethodBuilder>>parseSignature: FFICalloutMethodBuilder>>generate FFICalloutMethodBuilder>>build: FFICalloutAPI>>function:module: AthensCairoSurface class(Object)>>nbCall: AthensCairoSurface class>>primImage:width:height: AthensCairoSurface class>>extent:format: AthensCairoSurface class>>extent: AthensWrapMorph>>createSurface AthensWrapMorph>>initializeForNewSession AthensWrapMorph>>checkSurface AthensWrapMorph>>fullDrawOn: FormCanvas(Canvas)>>fullDraw: FormCanvas(Canvas)>>fullDrawMorph: [ :arg3 | arg3 fullDrawMorph: self ] in AthensWrapMorph(Morph)>>imageForm:forRectangle: in Block: [ :arg3 | arg3 fullDrawMorph: self ] FormCanvas>>translateBy:during: AthensWrapMorph(Morph)>>imageForm:forRectangle: AthensWrapMorph(Morph)>>imageFormForRectangle: AthensWrapMorph(Morph)>>iconOrThumbnail AthensWrapMorph(Morph)>>iconOrThumbnailOfSize: [ :arg3 | tmp1 add: arg3 class name asString target: arg3 selector: #addMorphFrontFromWorldPosition: argument: self topRendererOrSelf. tmp1 lastItem icon: (arg3 iconOrThumbnailOfSize: 16). self owner == arg3 ifTrue: [ tmp1 lastItem emphasis: 1 ] ] in DrGDrawable(Morph)>>addEmbeddingMenuItemsTo:hand: in Block: [ :arg3 | ... Array(SequenceableCollection)>>reverseDo: DrGDrawable(Morph)>>addEmbeddingMenuItemsTo:hand: DrGDrawable(Morph)>>addStandardHaloMenuItemsTo:hand: -- Dr. Geo http://drgeo.eu
On 17 December 2017 at 05:29, Hilaire <hilaire@drgeo.eu> wrote:
Hi,
With DrGeo built on image Pharo7.0-64bit-e41f921 Athens error shows up on the canvas (screenshot).
The drgeo dev. environment based on the older Pharo7.0-64bit-f82fc36 image does not have this error with the same VM.
The DrGeo build removes some pharo package but it is unlikely to produce such error, or so?
-- Dr. Geo http://drgeo.eu
Hi Hilaire, I'll have a try at reproducing your issue. Could you provide a download link to the VM you are using, and instructions how to load your project and trigger the problem. cheers -ben
Hi Ben, * The Linux 64 bits VM is the one coming from P6/P6.1, it is the only way to get one. * To install the project, fetch the src code from the DrGeo repo: bzr branch lp:drgeo * In the trunk/build/image directory install a virgin P7 image * You have to symlink /images/src to trunk/src * Adjust trunk/build/make-workstation-release script:    smalltalkImage and src variable. These make-workstation-script will be refactored some days with appropriate shell function. Le 20/12/2017 à 23:28, Ben Coman a écrit :
Hi Hilaire,
I'll have a try at reproducing your issue. Could you provide a download link to the VM you are using, and instructions how to load your project and trigger the problem.
cheers -ben
-- Dr. Geo http://drgeo.eu
participants (6)
-
Ben Coman -
Hilaire -
Igor Stasenko -
Nicolai Hess -
Pavel Krivanek -
Stephane Ducasse