June 2016 - Pharo-dev - lists.pharo.org

[ANN] Pharo Consortium New Bronze Member: FINWorks

by Marcus Denker

The Pharo Consortium is very happy to announce that FINWorks has joined the Consortium as a Bronze Member. FINWorks: http://finworks.biz FINWorks provides software solutions and automation in the financial sector. Our main area of focus is investment administration, especially back office solutions for LISP (Linked Investment Service Provider or Fund Supermarkets), Benefit Administrators, Unit Trust Companies, Asset Managers, Independent Financial Advisors (IFA) and other financial service providers Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org - https://salt.bountysource.com/teams/pharo

June 28, 2016

Re: [Pharo-dev] Smalltalk Hub on Chrome

by Ben Coman

On Tue, Jun 28, 2016 at 6:36 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > stepharo wrote >>> maybe we need to consider deprecate the amber client >>> and use a full-pharo version. >> >> Torsten what is the state of your solution? > > Is it worth it to take another trip down this road of rolling-our-own source > code repo? Whatever we create, we accept the responsibility to maintain, and > with GitHub's social coding features, BitBucket for free private repo > hosting, and all the advances in Pharo-git integration, it seems our limited > resources would be most effectively committed elsewhere... Jumping ahead to the end game of not needing to support development of the repository backend ourselves, there are a couple of levels to this... 1. Create a "SmalltalkHub" organisation on github and move *all* repositories (maintaining privacy. Synchronize between the two servers for a couple of years so as to not abandon old Pharo versions or break existing Configurations, or build a thin forwarding service such that requests received at smalltalkhub interact with github - perhaps this is read only. Build a thin web SmalltalkHub home page with github pages at smalltalkhub.io. 2. While GitHub gets most of the glory, its closed source and there are some open source git options to consider like GitLab (MIT license) or Gerrit (Apache license). This might be the path to choose if we need some Smalltalk customizations like Smalltalk syntax highlighting. The advantage of integrating with GitLab would be that the community could use their hosted solution, but private companies could run their own GitLab server if they have secrets they want to be more careful about sharing with third parties. 3. We might run a GitLab/Gerrit server in place of the existing Smalltalkhub server, and make it look the same for pre-git Pharo clients. There would still be some administration cost, but a larger community for support, features and bug fixing, or paid support options. * https://www.linux.com/learn/how-run-your-own-git-server * https://about.gitlab.com/applications/ * https://www.gerritcodereview.com/ * https://gerrit-review.googlesource.com/Documentation/config-plugins.html But these considerations shouldn't stop an intermediate solution. cheers -ben

June 28, 2016

Xtreams CardinalityMin Bug?

by Sean P. DeNigris

Parsing 'xxxxx' with the expression '"x"{2}' currently only consumes 'xx'. It seems that CardinalityRangeMin: min <action: 'CardinalityRangeMin'> ^[:expression | [parser repeat: expression min: min optional: *0*]] should be: CardinalityRangeMin: min <action: 'CardinalityRangeMin'> ^[:expression | [parser repeat: expression min: min optional: *PEGInfinity new*]] ----- Cheers, Sean -- View this message in context: http://forum.world.st/Xtreams-CardinalityMin-Bug-tp4903741.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 28, 2016

Re: [Pharo-dev] Smalltalk Hub on Chrome

by Sean P. DeNigris

stepharo wrote >> maybe we need to consider deprecate the amber client >> and use a full-pharo version. > > Torsten what is the state of your solution? Is it worth it to take another trip down this road of rolling-our-own source code repo? Whatever we create, we accept the responsibility to maintain, and with GitHub's social coding features, BitBucket for free private repo hosting, and all the advances in Pharo-git integration, it seems our limited resources would be most effectively committed elsewhere... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Smalltalk-Hub-on-Chrome-tp4755788p4903731.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 27, 2016

Re: [Pharo-dev] FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform, during save after initial load (pharo5.0)

by Dale Henrichs

On 06/27/2016 02:33 PM, Esteban Lorenzano wrote: > no, now that I remember I think it was because of the longlong conversion bugâ¦ which *should* be fixedâ¦ but I might be wrong, heh > > Esteban Ah yes , that does ring a bell .... I added the dependency[1] on Apr 5, long after the project was started --- Mariano did the early implementation work --- unfortunately I didn't mention in the commit comment why the dependency was added :) Thanks ... I'll wait (patiently) for the fix and then remove the dependency... Dale [1] https://github.com/GsDevKit/GemStone-GCI/commit/22e16a9b3c9b50f6afb778451de… > >> On 27 Jun 2016, at 23:21, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> Great thanks! ... I guess I started this project before UnifiedFFI was added to Pharo5.0? >> >> So I should be able to remove a dependency on this project moving forward? >> >> When you fix this bug, I assume that new Pharo5.0 images will be created with the patch already loaded, but what is the procedure for getting the patch into existing Pharo5.0 images? I'm expecting folks to be deploying images with this code loaded and in these cases, building from scratch may not be practical ... >> >> Dale >> >> On 06/27/2016 02:15 PM, Esteban Lorenzano wrote: >>> yeah, you do not need to load UFFI, afaikâ¦ it is already thereâ¦ Iâm missing something? >>> >>> and yes, not that Iâm seeingâ¦ seems that latest Alien update breaks UFFI because Callback has became a strategy and UFFI extends itâ¦ I need to think how to fix it, but most probably I need to transform FFICallback to delegate instead inherit. >>> >>> I will check this tomorrow. >>> >>> Esteban >>> >>>> On 27 Jun 2016, at 23:07, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >>>> >>>> spec >>>> for: #(#'pharo5.x') >>>> do: [ spec >>>> configuration: 'UnifiedFFI' >>>> with: [ spec >>>> versionString: #development; >>>> repository: 'http://http://smalltalkhub.com/mc/Pharo/FFI-NB/main/' ]; >>>> yourself. >>>> >>>> >>>> On 06/27/2016 01:50 PM, Dale Henrichs wrote: >>>>> I could have sworn this was working last week, but now I can't load the UnifiedFFI project. >>>>> >>>>> Here's the stack ... note that this appears to be breaking during a SmalltalkImage>>saveAs: call that I make after loading a project that depends up UnifiedFFI during a batch job ...: >>>>> >>>>> FFICallback class>>isForCurrentPlatform >>>>> FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform >>>>> [ :subclass | subclass isForCurrentPlatform ] in Callback class>>startUp: in Block: [ :subclass | subclass isForCurrentPlatform ] >>>>> [ :each | >>>>> (aBlock value: each) >>>>> ifTrue: [ ^ foundBlock cull: each ] ] in Array(Collection)>>detect:ifFound:ifNone: in Block: [ :each | ... >>>>> Array(SequenceableCollection)>>do: >>>>> Array(Collection)>>detect:ifFound:ifNone: >>>>> Array(Collection)>>detect:ifNone: >>>>> Callback class>>startUp: >>>>> ClassSessionHandler>>startup: >>>>> [ :each | each startup: isImageStarting ] in WorkingSession>>runStartup: in Block: [ :each | each startup: isImageStarting ] >>>>> [ aBlock value: each ] in [ :each | >>>>> [ aBlock value: each ] >>>>> on: Exception >>>>> do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ aBlock value: each ] >>>>> BlockClosure>>on:do: >>>>> [ :each | >>>>> [ aBlock value: each ] >>>>> on: Exception >>>>> do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ :each | ... >>>>> Array(SequenceableCollection)>>do: >>>>> WorkingSession>>runList:do: >>>>> WorkingSession>>runStartup: >>>>> WorkingSession>>start: >>>>> SessionManager>>snapshot:andQuit: >>>>> SmalltalkImage>>snapshot:andQuit: >>>>> SmalltalkImage>>saveImageInFileNamed: >>>>> SmalltalkImage>>saveAs: >>>>> SaveCommandLineHandler>>saveImage >>>>> SaveCommandLineHandler>>activate >>>>> SaveCommandLineHandler class(CommandLineHandler class)>>activateWith: >>>>> [ aCommandLinehandler activateWith: commandLine ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] >>>>> BlockClosure>>on:do: >>>>> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: >>>>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand >>>>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: >>>>> [ self >>>>> handleArgument: >>>>> (self arguments >>>>> ifEmpty: [ '' ] >>>>> ifNotEmpty: [ :arguments | arguments first ]) ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self... >>>>> BlockClosure>>on:do: >>>>> >> >

June 27, 2016

Re: [Pharo-dev] FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform, during save after initial load (pharo5.0)

by Esteban Lorenzano

no, now that I remember I think it was because of the longlong conversion bugâ¦ which *should* be fixedâ¦ but I might be wrong, heh Esteban > On 27 Jun 2016, at 23:21, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Great thanks! ... I guess I started this project before UnifiedFFI was added to Pharo5.0? > > So I should be able to remove a dependency on this project moving forward? > > When you fix this bug, I assume that new Pharo5.0 images will be created with the patch already loaded, but what is the procedure for getting the patch into existing Pharo5.0 images? I'm expecting folks to be deploying images with this code loaded and in these cases, building from scratch may not be practical ... > > Dale > > On 06/27/2016 02:15 PM, Esteban Lorenzano wrote: >> yeah, you do not need to load UFFI, afaikâ¦ it is already thereâ¦ Iâm missing something? >> >> and yes, not that Iâm seeingâ¦ seems that latest Alien update breaks UFFI because Callback has became a strategy and UFFI extends itâ¦ I need to think how to fix it, but most probably I need to transform FFICallback to delegate instead inherit. >> >> I will check this tomorrow. >> >> Esteban >> >>> On 27 Jun 2016, at 23:07, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> spec >>> for: #(#'pharo5.x') >>> do: [ spec >>> configuration: 'UnifiedFFI' >>> with: [ spec >>> versionString: #development; >>> repository: 'http://http://smalltalkhub.com/mc/Pharo/FFI-NB/main/' ]; >>> yourself. >>> >>> >>> On 06/27/2016 01:50 PM, Dale Henrichs wrote: >>>> I could have sworn this was working last week, but now I can't load the UnifiedFFI project. >>>> >>>> Here's the stack ... note that this appears to be breaking during a SmalltalkImage>>saveAs: call that I make after loading a project that depends up UnifiedFFI during a batch job ...: >>>> >>>> FFICallback class>>isForCurrentPlatform >>>> FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform >>>> [ :subclass | subclass isForCurrentPlatform ] in Callback class>>startUp: in Block: [ :subclass | subclass isForCurrentPlatform ] >>>> [ :each | >>>> (aBlock value: each) >>>> ifTrue: [ ^ foundBlock cull: each ] ] in Array(Collection)>>detect:ifFound:ifNone: in Block: [ :each | ... >>>> Array(SequenceableCollection)>>do: >>>> Array(Collection)>>detect:ifFound:ifNone: >>>> Array(Collection)>>detect:ifNone: >>>> Callback class>>startUp: >>>> ClassSessionHandler>>startup: >>>> [ :each | each startup: isImageStarting ] in WorkingSession>>runStartup: in Block: [ :each | each startup: isImageStarting ] >>>> [ aBlock value: each ] in [ :each | >>>> [ aBlock value: each ] >>>> on: Exception >>>> do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ aBlock value: each ] >>>> BlockClosure>>on:do: >>>> [ :each | >>>> [ aBlock value: each ] >>>> on: Exception >>>> do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ :each | ... >>>> Array(SequenceableCollection)>>do: >>>> WorkingSession>>runList:do: >>>> WorkingSession>>runStartup: >>>> WorkingSession>>start: >>>> SessionManager>>snapshot:andQuit: >>>> SmalltalkImage>>snapshot:andQuit: >>>> SmalltalkImage>>saveImageInFileNamed: >>>> SmalltalkImage>>saveAs: >>>> SaveCommandLineHandler>>saveImage >>>> SaveCommandLineHandler>>activate >>>> SaveCommandLineHandler class(CommandLineHandler class)>>activateWith: >>>> [ aCommandLinehandler activateWith: commandLine ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] >>>> BlockClosure>>on:do: >>>> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: >>>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand >>>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: >>>> [ self >>>> handleArgument: >>>> (self arguments >>>> ifEmpty: [ '' ] >>>> ifNotEmpty: [ :arguments | arguments first ]) ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self... >>>> BlockClosure>>on:do: >>>> >>> >> > >

June 27, 2016

Re: [Pharo-dev] FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform, during save after initial load (pharo5.0)

by Dale Henrichs

Great thanks! ... I guess I started this project before UnifiedFFI was added to Pharo5.0? So I should be able to remove a dependency on this project moving forward? When you fix this bug, I assume that new Pharo5.0 images will be created with the patch already loaded, but what is the procedure for getting the patch into existing Pharo5.0 images? I'm expecting folks to be deploying images with this code loaded and in these cases, building from scratch may not be practical ... Dale On 06/27/2016 02:15 PM, Esteban Lorenzano wrote: > yeah, you do not need to load UFFI, afaikâ¦ it is already thereâ¦ Iâm missing something? > > and yes, not that Iâm seeingâ¦ seems that latest Alien update breaks UFFI because Callback has became a strategy and UFFI extends itâ¦ I need to think how to fix it, but most probably I need to transform FFICallback to delegate instead inherit. > > I will check this tomorrow. > > Esteban > >> On 27 Jun 2016, at 23:07, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> spec >> for: #(#'pharo5.x') >> do: [ spec >> configuration: 'UnifiedFFI' >> with: [ spec >> versionString: #development; >> repository: 'http://http://smalltalkhub.com/mc/Pharo/FFI-NB/main/' ]; >> yourself. >> >> >> On 06/27/2016 01:50 PM, Dale Henrichs wrote: >>> I could have sworn this was working last week, but now I can't load the UnifiedFFI project. >>> >>> Here's the stack ... note that this appears to be breaking during a SmalltalkImage>>saveAs: call that I make after loading a project that depends up UnifiedFFI during a batch job ...: >>> >>> FFICallback class>>isForCurrentPlatform >>> FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform >>> [ :subclass | subclass isForCurrentPlatform ] in Callback class>>startUp: in Block: [ :subclass | subclass isForCurrentPlatform ] >>> [ :each | >>> (aBlock value: each) >>> ifTrue: [ ^ foundBlock cull: each ] ] in Array(Collection)>>detect:ifFound:ifNone: in Block: [ :each | ... >>> Array(SequenceableCollection)>>do: >>> Array(Collection)>>detect:ifFound:ifNone: >>> Array(Collection)>>detect:ifNone: >>> Callback class>>startUp: >>> ClassSessionHandler>>startup: >>> [ :each | each startup: isImageStarting ] in WorkingSession>>runStartup: in Block: [ :each | each startup: isImageStarting ] >>> [ aBlock value: each ] in [ :each | >>> [ aBlock value: each ] >>> on: Exception >>> do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ aBlock value: each ] >>> BlockClosure>>on:do: >>> [ :each | >>> [ aBlock value: each ] >>> on: Exception >>> do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ :each | ... >>> Array(SequenceableCollection)>>do: >>> WorkingSession>>runList:do: >>> WorkingSession>>runStartup: >>> WorkingSession>>start: >>> SessionManager>>snapshot:andQuit: >>> SmalltalkImage>>snapshot:andQuit: >>> SmalltalkImage>>saveImageInFileNamed: >>> SmalltalkImage>>saveAs: >>> SaveCommandLineHandler>>saveImage >>> SaveCommandLineHandler>>activate >>> SaveCommandLineHandler class(CommandLineHandler class)>>activateWith: >>> [ aCommandLinehandler activateWith: commandLine ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] >>> BlockClosure>>on:do: >>> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: >>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand >>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: >>> [ self >>> handleArgument: >>> (self arguments >>> ifEmpty: [ '' ] >>> ifNotEmpty: [ :arguments | arguments first ]) ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self... >>> BlockClosure>>on:do: >>> >> >

June 27, 2016

Re: [Pharo-dev] FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform, during save after initial load (pharo5.0)

by Esteban Lorenzano

yeah, you do not need to load UFFI, afaikâ¦ it is already thereâ¦ Iâm missing something? and yes, not that Iâm seeingâ¦ seems that latest Alien update breaks UFFI because Callback has became a strategy and UFFI extends itâ¦ I need to think how to fix it, but most probably I need to transform FFICallback to delegate instead inherit. I will check this tomorrow. Esteban > On 27 Jun 2016, at 23:07, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > spec > for: #(#'pharo5.x') > do: [ spec > configuration: 'UnifiedFFI' > with: [ spec > versionString: #development; > repository: 'http://http://smalltalkhub.com/mc/Pharo/FFI-NB/main/' ]; > yourself. > > > On 06/27/2016 01:50 PM, Dale Henrichs wrote: >> I could have sworn this was working last week, but now I can't load the UnifiedFFI project. >> >> Here's the stack ... note that this appears to be breaking during a SmalltalkImage>>saveAs: call that I make after loading a project that depends up UnifiedFFI during a batch job ...: >> >> FFICallback class>>isForCurrentPlatform >> FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform >> [ :subclass | subclass isForCurrentPlatform ] in Callback class>>startUp: in Block: [ :subclass | subclass isForCurrentPlatform ] >> [ :each | >> (aBlock value: each) >> ifTrue: [ ^ foundBlock cull: each ] ] in Array(Collection)>>detect:ifFound:ifNone: in Block: [ :each | ... >> Array(SequenceableCollection)>>do: >> Array(Collection)>>detect:ifFound:ifNone: >> Array(Collection)>>detect:ifNone: >> Callback class>>startUp: >> ClassSessionHandler>>startup: >> [ :each | each startup: isImageStarting ] in WorkingSession>>runStartup: in Block: [ :each | each startup: isImageStarting ] >> [ aBlock value: each ] in [ :each | >> [ aBlock value: each ] >> on: Exception >> do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ aBlock value: each ] >> BlockClosure>>on:do: >> [ :each | >> [ aBlock value: each ] >> on: Exception >> do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ :each | ... >> Array(SequenceableCollection)>>do: >> WorkingSession>>runList:do: >> WorkingSession>>runStartup: >> WorkingSession>>start: >> SessionManager>>snapshot:andQuit: >> SmalltalkImage>>snapshot:andQuit: >> SmalltalkImage>>saveImageInFileNamed: >> SmalltalkImage>>saveAs: >> SaveCommandLineHandler>>saveImage >> SaveCommandLineHandler>>activate >> SaveCommandLineHandler class(CommandLineHandler class)>>activateWith: >> [ aCommandLinehandler activateWith: commandLine ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] >> BlockClosure>>on:do: >> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: >> PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand >> PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: >> [ self >> handleArgument: >> (self arguments >> ifEmpty: [ '' ] >> ifNotEmpty: [ :arguments | arguments first ]) ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self... >> BlockClosure>>on:do: >> > >

June 27, 2016

Re: [Pharo-dev] FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform, during save after initial load (pharo5.0)

by Dale Henrichs

spec for: #(#'pharo5.x') do: [ spec configuration: 'UnifiedFFI' with: [ spec versionString: #development; repository: 'http://http://smalltalkhub.com/mc/Pharo/FFI-NB/main/' ]; yourself. On 06/27/2016 01:50 PM, Dale Henrichs wrote: > I could have sworn this was working last week, but now I can't load > the UnifiedFFI project. > > Here's the stack ... note that this appears to be breaking during a > SmalltalkImage>>saveAs: call that I make after loading a project that > depends up UnifiedFFI during a batch job ...: > > FFICallback class>>isForCurrentPlatform > FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform > [ :subclass | subclass isForCurrentPlatform ] in Callback > class>>startUp: in Block: [ :subclass | subclass isForCurrentPlatform ] > [ :each | > (aBlock value: each) > ifTrue: [ ^ foundBlock cull: each ] ] in > Array(Collection)>>detect:ifFound:ifNone: in Block: [ :each | ... > Array(SequenceableCollection)>>do: > Array(Collection)>>detect:ifFound:ifNone: > Array(Collection)>>detect:ifNone: > Callback class>>startUp: > ClassSessionHandler>>startup: > [ :each | each startup: isImageStarting ] in > WorkingSession>>runStartup: in Block: [ :each | each startup: > isImageStarting ] > [ aBlock value: each ] in [ :each | > [ aBlock value: each ] > on: Exception > do: [ :error | self errorHandler handleError: error ] ] in > WorkingSession>>runList:do: in Block: [ aBlock value: each ] > BlockClosure>>on:do: > [ :each | > [ aBlock value: each ] > on: Exception > do: [ :error | self errorHandler handleError: error ] ] in > WorkingSession>>runList:do: in Block: [ :each | ... > Array(SequenceableCollection)>>do: > WorkingSession>>runList:do: > WorkingSession>>runStartup: > WorkingSession>>start: > SessionManager>>snapshot:andQuit: > SmalltalkImage>>snapshot:andQuit: > SmalltalkImage>>saveImageInFileNamed: > SmalltalkImage>>saveAs: > SaveCommandLineHandler>>saveImage > SaveCommandLineHandler>>activate > SaveCommandLineHandler class(CommandLineHandler class)>>activateWith: > [ aCommandLinehandler activateWith: commandLine ] in > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: > in Block: [ aCommandLinehandler activateWith: commandLine ] > BlockClosure>>on:do: > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: > PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand > PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: > [ self > handleArgument: > (self arguments > ifEmpty: [ '' ] > ifNotEmpty: [ :arguments | arguments first ]) ] in > PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ > self... > BlockClosure>>on:do: >

June 27, 2016

Re: [Pharo-dev] FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform, during save after initial load (pharo5.0)

by Esteban Lorenzano

> On 27 Jun 2016, at 23:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi Dale, > > where are you trying to load UFFI? and how? > > Esteban > >> On 27 Jun 2016, at 22:50, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> I could have sworn this was working last week, but now I can't load the UnifiedFFI project. >> >> Here's the stack ... note that this appears to be breaking during a SmalltalkImage>>saveAs: call that I make after loading a project that depends up UnifiedFFI during a batch job ...: >> >> FFICallback class>>isForCurrentPlatform >> FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform >> [ :subclass | subclass isForCurrentPlatform ] in Callback class>>startUp: in Block: [ :subclass | subclass isForCurrentPlatform ] >> [ :each | >> (aBlock value: each) >> ifTrue: [ ^ foundBlock cull: each ] ] in Array(Collection)>>detect:ifFound:ifNone: in Block: [ :each | ... >> Array(SequenceableCollection)>>do: >> Array(Collection)>>detect:ifFound:ifNone: >> Array(Collection)>>detect:ifNone: >> Callback class>>startUp: >> ClassSessionHandler>>startup: >> [ :each | each startup: isImageStarting ] in WorkingSession>>runStartup: in Block: [ :each | each startup: isImageStarting ] >> [ aBlock value: each ] in [ :each | >> [ aBlock value: each ] >> on: Exception >> do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ aBlock value: each ] >> BlockClosure>>on:do: >> [ :each | >> [ aBlock value: each ] >> on: Exception >> do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ :each | ... >> Array(SequenceableCollection)>>do: >> WorkingSession>>runList:do: >> WorkingSession>>runStartup: >> WorkingSession>>start: >> SessionManager>>snapshot:andQuit: >> SmalltalkImage>>snapshot:andQuit: >> SmalltalkImage>>saveImageInFileNamed: >> SmalltalkImage>>saveAs: >> SaveCommandLineHandler>>saveImage >> SaveCommandLineHandler>>activate >> SaveCommandLineHandler class(CommandLineHandler class)>>activateWith: >> [ aCommandLinehandler activateWith: commandLine ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] >> BlockClosure>>on:do: >> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: >> PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand >> PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: >> [ self >> handleArgument: >> (self arguments >> ifEmpty: [ '' ] >> ifNotEmpty: [ :arguments | arguments first ]) ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self... >> BlockClosure>>on:do: >> >> >

June 27, 2016