July 2012 - Pharo-dev - lists.pharo.org

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

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

by Igor Stasenko

Ok the problem is that it doesn't compiles. The mingw/msys header (wincrypt.h) missing a number of definitions used by SqWin32SSL.c which i tried to add manually, to make it compile, but then on linking stage it fails with following: Creating library file: c:/COG/blessed/results/libSqueakSSL.dll.a CMakeFiles/SqueakSSL.dir/objects.a(sqWin32SSL.c.obj):sqWin32SSL.c:(.text+0x4d0): undefined reference to `CertFindRDNAttr@8' CMakeFiles/SqueakSSL.dir/objects.a(sqWin32SSL.c.obj):sqWin32SSL.c:(.text+0x508): undefined reference to `CertRDNValueToStr' of course, because libcrypt.dll.a file which also part of mingw seems to be missing exports for these symbols. unless there is workaround to not call these function(s) i don't see what can be done, at least by me. maybe updating mingw could solve that problem.. ---------------- Name: CMakeVMMaker-IgorStasenko.171 Author: IgorStasenko Time: 5 July 2012, 5:43:02.685 pm UUID: 542b4f30-481c-754e-adc6-df26d22df280 Ancestors: CMakeVMMaker-EstebanLorenzano.170 - added configuration for ssl plugin on windows (but it doesn't builds on my mingw installation, a lot of missing definitions in Wincrypt.h ) To try it, use ------- CogWindowsConfig new addExternalPlugins: #( SqueakSSLPlugin ); generateSources; generate -- Best regards, Igor Stasenko.

July 5, 2012

Re: [Pharo-project] ScriptManager for Pharo 2.0 also with code completion

by Sean P. DeNigris

Torsten Bergmann wrote > > you can easily load ScriptManager using > Thanks, Torsten! -- View this message in context: http://forum.world.st/ScriptManager-for-Pharo-2-0-also-with-code-completion… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 5, 2012

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

by StÃ©phane Ducasse

igor and for the second problem? 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

July 5, 2012

[Pharo-project] ScriptManager for Pharo 2.0 also with code completion

by Torsten Bergmann

Note that with the latest update for Pharo 2.0 ([update 2.0] #20185) or the latest one click image https://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0/lastSuccessf… you can easily load ScriptManager using Tools -> ConfigurationBrowser -> click on "ScriptManager" and select "Install configuration (Stable version)" After loading go to "Tools" -> "ScriptManager" Note that ScriptManager is now using Fuel for exporting/importing which is not compatible with the old ReferenceStream. It now exports into *.fuel files instead of *.obj. Have fun T.

July 5, 2012

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

by Goubier Thierry

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. > | > | > 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. 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). 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? 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. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 5, 2012