- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Putting Cairo in the VM?

by StÃ©phane Ducasse

do you mean 1.1 because I could not find a 1.2.1 version I checked and it looks like I loaded the correct version. > (Smalltalk globals classNamed: 'ConfigurationOfAthens') loadBleedingEdge. > > try load exact version of it, or make sure you loaded latest version: > > ConfigurationOfAthens loadVersion: '1.2.1'. > > i do not know what it loads when you call loadBleedingEdge.. > > >> >> On Jul 5, 2012, at 2:44 PM, StÃ©phane Ducasse wrote: >> >>> second >>> loadSymbol: aSymbolName fromModule: moduleName >>> >>> (moduleName = '' or: [moduleName = 0 ]) ifTrue: [ >>> "if module name is empty, try to retrieve symbol from globals " >>> ^ self getGlobalSymbolPointer: aSymbolName >>> ]. >>> ^ super loadSymbol: aSymbolName fromModule: moduleName >>> >>> >>> >>> error: aString >>> "Throw a generic Error exception." >>> >>> ^Error new signal: aString >>> >>> >>> 'failed to get a symbol address: cairo_image_surface_create' >>> >>> here is what I did >> >> > > > > -- > Best regards, > Igor Stasenko. >

July 5, 2012

Re: [Pharo-project] Putting Cairo in the VM?

by StÃ©phane Ducasse

I can reopen the image fernando sent me with the new vm. Stef On Jul 5, 2012, at 8:02 PM, StÃ©phane Ducasse wrote: > What is strange is that I cannot reopen the image I saved. > I reopen it with exactly the same VM that I did before but not impossible it crashes directly. > > Stef > > > On Jul 5, 2012, at 7:33 PM, Igor Stasenko wrote: > >> On 5 July 2012 16:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> igor and for the second problem? >>> >> i think this is the problem: >> >> (Smalltalk globals classNamed: 'ConfigurationOfAthens') loadBleedingEdge. >> >> try load exact version of it, or make sure you loaded latest version: >> >> ConfigurationOfAthens loadVersion: '1.2.1'. >> >> i do not know what it loads when you call loadBleedingEdge.. >> >> >>> >>> On Jul 5, 2012, at 2:44 PM, StÃ©phane Ducasse wrote: >>> >>>> second >>>> loadSymbol: aSymbolName fromModule: moduleName >>>> >>>> (moduleName = '' or: [moduleName = 0 ]) ifTrue: [ >>>> "if module name is empty, try to retrieve symbol from globals " >>>> ^ self getGlobalSymbolPointer: aSymbolName >>>> ]. >>>> ^ super loadSymbol: aSymbolName fromModule: moduleName >>>> >>>> >>>> >>>> error: aString >>>> "Throw a generic Error exception." >>>> >>>> ^Error new signal: aString >>>> >>>> >>>> 'failed to get a symbol address: cairo_image_surface_create' >>>> >>>> here is what I did >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

July 5, 2012

Re: [Pharo-project] Putting Cairo in the VM?

by StÃ©phane Ducasse

What is strange is that I cannot reopen the image I saved. I reopen it with exactly the same VM that I did before but not impossible it crashes directly. Stef On Jul 5, 2012, at 7:33 PM, Igor Stasenko wrote: > On 5 July 2012 16:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> igor and for the second problem? >> > i think this is the problem: > > (Smalltalk globals classNamed: 'ConfigurationOfAthens') loadBleedingEdge. > > try load exact version of it, or make sure you loaded latest version: > > ConfigurationOfAthens loadVersion: '1.2.1'. > > i do not know what it loads when you call loadBleedingEdge.. > > >> >> On Jul 5, 2012, at 2:44 PM, StÃ©phane Ducasse wrote: >> >>> second >>> loadSymbol: aSymbolName fromModule: moduleName >>> >>> (moduleName = '' or: [moduleName = 0 ]) ifTrue: [ >>> "if module name is empty, try to retrieve symbol from globals " >>> ^ self getGlobalSymbolPointer: aSymbolName >>> ]. >>> ^ super loadSymbol: aSymbolName fromModule: moduleName >>> >>> >>> >>> error: aString >>> "Throw a generic Error exception." >>> >>> ^Error new signal: aString >>> >>> >>> 'failed to get a symbol address: cairo_image_surface_create' >>> >>> here is what I did >> >> > > > > -- > Best regards, > Igor Stasenko. >

July 5, 2012

Re: [Pharo-project] SSL plugins in Jenkins one click

by Igor Stasenko

On 5 July 2012 19:49, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Igor Stasenko wrote >> >> didn't helped.. the functions/definitions are still missing in mingw >> header files. >> > > Is this relevant? > http://msdn.microsoft.com/en-us/library/windows/desktop/aa376069(v=vs.85).a… > relevant to what? i declared those two functions in .c file but linker cannot find them in corresponding .dll.a file .. but you can look by yourself at an ugly hacks(attached) we're made with Camillo, trying to see if it just missing declarations and nothing else. > -- > View this message in context: http://forum.world.st/SSL-plugins-in-Jenkins-one-click-tp4638530p4638588.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

July 5, 2012

Re: [Pharo-project] SSL plugins in Jenkins one click

by Sean P. DeNigris

Igor Stasenko wrote > > didn't helped.. the functions/definitions are still missing in mingw > header files. > Is this relevant? http://msdn.microsoft.com/en-us/library/windows/desktop/aa376069(v=vs.85).a… -- View this message in context: http://forum.world.st/SSL-plugins-in-Jenkins-one-click-tp4638530p4638588.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 5, 2012

Re: [Pharo-project] Putting Cairo in the VM?

by Igor Stasenko

On 5 July 2012 16:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > igor and for the second problem? > i think this is the problem: (Smalltalk globals classNamed: 'ConfigurationOfAthens') loadBleedingEdge. try load exact version of it, or make sure you loaded latest version: ConfigurationOfAthens loadVersion: '1.2.1'. i do not know what it loads when you call loadBleedingEdge.. > > On Jul 5, 2012, at 2:44 PM, StÃ©phane Ducasse wrote: > >> second >> loadSymbol: aSymbolName fromModule: moduleName >> >> (moduleName = '' or: [moduleName = 0 ]) ifTrue: [ >> "if module name is empty, try to retrieve symbol from globals " >> ^ self getGlobalSymbolPointer: aSymbolName >> ]. >> ^ super loadSymbol: aSymbolName fromModule: moduleName >> >> >> >> error: aString >> "Throw a generic Error exception." >> >> ^Error new signal: aString >> >> >> 'failed to get a symbol address: cairo_image_surface_create' >> >> here is what I did > > -- Best regards, Igor Stasenko.

July 5, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Dale Henrichs

----- Original Message ----- | From: "Goubier Thierry" <thierry.goubier(a)cea.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Thursday, July 5, 2012 7:37:18 AM | Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub | | Le 05/07/2012 15:59, Dale Henrichs a Ã©crit : | > | It still shows that the Smalltalk/via Filetree model isn't the | > | one | > | git | > | expects, but we do benefit from it. I'm also not certain git | > | would | > | follow class renames. | > | > There aren't really any files outside of the properties file that | > are associated with a class in this model, so there's nothing | > explicit to track ... the methods in the class will be tracked | > nicely (as a rename). | | So that's different from the current FileTree format then ? The | FileTree | I do use has .class directories. Not different. .class directories are used, but directories aren't objects in git ... only files are managed ... directory structure is simply reflected in the "name" of the file ... so changing a directory name (rename class) shows up as renaming all of the files under that directory. There isn't an explicit file that represents the class itself other than the properties file in .class directory ... | | > | | > | > multiple files makes reading source on disk a bit awkward, but | > | > that's what we've got the Smalltalk image for ... how many | > | > people | > | > out there unzip their .mcz files to read Smalltalk source? | > | | > | Me! | > | | > | I do open .mcz files at times; I appreciate the fact it's as | > | easy as | > | clicking on it and then search into the produced files. | > | | > | The fact that Linux recognize them as zip archives helps, too. | > | > Haha...well the directory structure is searchable, too .. just a | > more complicated incantation:) | | Yes, that's true. Both formats are nice in my opinion: mcz since they | can easily be carried around and have a nice way of showing version | and | developper; and the a file per method, a directory for a class is ok | too. Agreed, not perfect, but the current structure is navigable. | | So far, in my experience, all version control systems have to be | "encaged" in a set of rules of use to fit the work culture of the | team, | group or lab. At the moment, I'm not entirely sure of the rules | followed | in the Pharo culture, so I'm a bit hesitant to raise issues (and tend | to | bring along a small set of changes to be made each time I restart | from a | fresh Pharo image, including a few gophers to get the packages I | need). Right now we are in the very early stages of learning how to use git with Smalltalk ... FileTree is the first step, but it is clear that we need more work ... FileTree is perfectly usable for folks that are comfortable with git and the command line, but it's not for everyone. We need a bit more tools support ... and development is under way, but not yet fully integrated into the development environment ... we are still gaining experience and in the process of discovering best practices for Smalltalk. | | Maybe a small documentation about how to keep an image up-to-date? | How | to deal with slices? A way to extract all the changes on a package as | a | change set? Once we have Metacello support for git/github, then I'll write some documentation ... right now I have a workspace that looks like the following: Metacello new baseline: 'Metacello'; repository: 'filetree:///opt/git/metacello-work/repository'; load. Metacello new baseline: 'FileTree'; repository: 'filetree:///opt/git/filetree/repository'; load. for refreshing my image from the git repositories, but I also may do something a bit more automatic[1], but I haven't quite gotten to that point in my development:) [1] https://github.com/dalehenrich/metacello-work/issues/33 | | In a way, Monticello is very convincing and powerfull (maybe just | because it works as it is and is integrated), and in others, it's | annoying to see how more powerfull and better it could be. There's always room for improvement, but there's not always the time:) Dale

July 5, 2012

Re: [Pharo-project] SSL plugins in Jenkins one click

by Igor Stasenko

On 5 July 2012 17:44, Igor Stasenko <siguctua(a)gmail.com> wrote: > maybe updating mingw could solve that problem.. > didn't helped.. the functions/definitions are still missing in mingw header files. -- Best regards, Igor Stasenko.

July 5, 2012

Re: [Pharo-project] SSL plugins in Jenkins one click

by Esteban Lorenzano

yes... if it is just a matter of copy&paste, all the maintainability of the system become: nil... now, we want to create a process that is reproducible and sustainably in time, and not just for a bunch of people (no matter how cool is that people, they might be not here tomorrow). of course, that makes the process has it's annoyances... but we hope to improve with effort (and time, but effort first :) Esteban On Jul 5, 2012, at 5:52 PM, Igor Stasenko wrote: > As for including (copy/pasting) prebuilt binary, i am strongly against it. > > We should have the way to reproduce things we use.. > Otherwise how we can take responsibility for maintaining it, testing > it , etc etc? > > If they are not reproducible, then it obviously cannot be a part of > distribution > (users should download & use these binaries at their own risk and > contact with original author/maintainer > concerning all problems with it). > > > -- > Best regards, > Igor Stasenko. >

July 5, 2012

Re: [Pharo-project] SSL plugins in Jenkins one click

by Igor Stasenko

As for including (copy/pasting) prebuilt binary, i am strongly against it. We should have the way to reproduce things we use.. Otherwise how we can take responsibility for maintaining it, testing it , etc etc? If they are not reproducible, then it obviously cannot be a part of distribution (users should download & use these binaries at their own risk and contact with original author/maintainer concerning all problems with it). -- Best regards, Igor Stasenko.

July 5, 2012