April 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Security in the image

by Ben Coman

On Wed, Apr 12, 2017 at 3:34 PM, LaeMing <laeming(a)exemail.com.au> wrote: > Hi, I am fishing about for an environment to try to develop a simple > virtual > world system in (yes, I'm aware of croquet/cobolt!). > > In a smalltalk-like environment, that might conceivably involve inviting > multiple people into the 'image' where the world is hosted to interact with > objects within it (if I was to use a smalltalk, it would want it to > interleave the entire system, not just host it on top.) > > What sort of security implications might that have and are there any > current > solutions to a multi-user single-image situation? > If you want hostile actors working directly within the Image with a full environment, then Pharo is probably not suitable. Its easy to get hold of global class from the Playground references and overwrite/compile any method in the system like this... SomeClass compile: 'initialize MyEvilHack dostuff. ^ super initialize ' You might want to consider Newspeak, which runs on the same VM as Pharo and has a focus on security. * https://www.slideshare.net/esug/8-gilad-brachaesug08 * https://www.youtube.com/watch?v=UwkROn7OmNQ cheers -ben

April 12, 2017

Re: [Pharo-dev] Alien osVersion is not defined. Pharo 5

by Esteban Lorenzano

Hi, In Pharo, Alien is included as backend for UFFI but is not recommended to use it directly. Instead, I invite you to see the class FFICallback and the method FFICallback class>>exampleCqsort. if you insist, wellâ¦ you can just modify that method to point where you wantâ¦ now, I insistâ¦ why that if you have UFFI? Esteban > On 12 Apr 2017, at 18:04, nacho <0800nacho(a)gmail.com> wrote: > > Hi! > I've been trying to run some examples from Alien. > It seems that the method 'osVersion' is not defined anymore and that method > is used in: > Allien class>>libcName > I guess it was a method that was removed from SmalltalkImage. > Any work around? > Thanks! > Nacho > > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: http://forum.world.st/Alien-osVersion-is-not-defined-Pharo-5-tp4941906.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

April 12, 2017

Re: [Pharo-dev] Please, test our 64bits builds

by Esteban Lorenzano

forget to say that iceberg will not work 100% yet :) but here, problem is because you need to install the threaded version, which of course I forget to point :P curl get.pharo.org/64/60+vmTLatest | bash this is the correct one for linux users. Esteban > On 12 Apr 2017, at 17:23, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Esteban, > > On Wed, Apr 12, 2017 at 04:44:51PM +0200, Esteban Lorenzano wrote: >> Hello list, >> >> We are approaching to release and one big thing of this one is the >> 64bits supports for Pharo (limited, since there is still not support >> for Windows, but it will arrive, eventually ;) ) I asked you to test a >> couple of months ago but now we are in better shape to do it. >> >> - VM and image are getting more and more stable and crashes >> shouldn???t happen (but that???s why I want you to test: to discover >> possible bugs/crashes) - I made 64bits a zeroconf citizen: >> http://get.pharo.org/64 >> >> Now, you can test it by just doing: >> >> curl get.pharo.org/64/60+vmLatest | bash (In linux or mac, remember it >> will not work for Windows) > > I'm getting: > > LGit_GIT_ERROR: no error message set by libgit2 > > (full stack below) > > while executing: > > Metacello new > githubUser: 'pharophile' > project: 'TilingWindowManager' > commitish: 'master' > path: 'packages'; > baseline: 'TilingWindowManager'; > onWarningLog; > load. > > > Checking that libgit2.so is OK produces: > > $ ldd libgit2.so > ./libgit2.so: > /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libssl.so.1.0.0: no > version information available (required by > /usr/lib/x86_64-linux-gnu/libcurl.so.4) > ./libgit2.so: > /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libssl.so.1.0.0: no > version information available (required by > /usr/lib/x86_64-linux-gnu/libcurl.so.4) > ./libgit2.so: > /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libssl.so.1.0.0: no > version information available (required by > /usr/lib/x86_64-linux-gnu/libcurl.so.4) > ./libgit2.so: > /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libcrypto.so.1.0.0: no > version information available (required by > /usr/lib/x86_64-linux-gnu/libcurl.so.4) > linux-vdso.so.1 => (0x00007ffde370e000) > libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 > (0x00007f3b11727000) > libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 > (0x00007f3b1150d000) > libssl.so.1.0.0 => > /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libssl.so.1.0.0 > (0x00007f3b1129c000) > libcrypto.so.1.0.0 => > /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libcrypto.so.1.0.0 > (0x00007f3b10ebf000) > libssh2.so.1 => > /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libssh2.so.1 > (0x00007f3b10c86000) > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 > (0x00007f3b10a7d000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x00007f3b10860000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 > (0x00007f3b10497000) > libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 > (0x00007f3b10263000) > librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 > (0x00007f3b10047000) > libgssapi_krb5.so.2 => > /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f3b0fdfd000) > liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 > (0x00007f3b0fbed000) > libldap_r-2.4.so.2 => > /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f3b0f99c000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 > (0x00007f3b0f798000) > /lib64/ld-linux-x86-64.so.2 (0x0000561a2abc3000) > libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 > (0x00007f3b0f467000) > libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 > (0x00007f3b0f234000) > libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 > (0x00007f3b0effd000) > libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 > (0x00007f3b0ed7d000) > libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 > (0x00007f3b0eaab000) > libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 > (0x00007f3b0e87b000) > libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 > (0x00007f3b0e677000) > libkrb5support.so.0 => > /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f3b0e46c000) > libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 > (0x00007f3b0e250000) > libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 > (0x00007f3b0e035000) > libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 > (0x00007f3b0ddf4000) > libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 > (0x00007f3b0db8f000) > libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 > (0x00007f3b0d97c000) > libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 > (0x00007f3b0d778000) > libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 > (0x00007f3b0d56e000) > libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 > (0x00007f3b0d2e4000) > libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 > (0x00007f3b0d041000) > libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 > (0x00007f3b0ce0e000) > libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 > (0x00007f3b0cbf8000) > libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 > (0x00007f3b0c9ef000) > libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 > (0x00007f3b0c7c6000) > libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 > (0x00007f3b0c5b7000) > libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 > (0x00007f3b0c36b000) > libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 > (0x00007f3b0c096000) > libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 > (0x00007f3b0be5e000) > > > The first few lines look dodgy to me. Searching on google (admittedly > briefly) it wasn't clear to me whether this is a fatal error or just a > warning. Most of the responses suggest recompiling with matching > versions, symbols, etc. > > Is there something else you'd like me to try? I can have a go at > compiling if you think it will help. > > Cheers, > Alistair > > > LGitReturnCodeEnum>>handleLGitReturnCode > LGitRepository(LGitExternalObject)>>withReturnHandlerDo: > LGitRepository>>clone:options:to: > LGitRepository>>clone:options: > [ | repo cloneOptions | > repo := LGitRepository on: self location. > cloneOptions := LGitCloneOptions > withCredentialsProvider: IceCredentialsProvider default. > repo clone: url options: cloneOptions. > aBranchName ifNotNil: [ repo checkout: aBranchName ]. > (LGitRemote of: repo named: 'origin') > lookup; > setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... > [ self checkInitialized. > aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self checkInitialized.... > [ activeProcess psValueAt: index put: anObject. > aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... > BlockClosure>>ensure: > LGitActionSequence(DynamicVariable)>>value:during: > LGitActionSequence class(DynamicVariable class)>>value:during: > LGitGlobal class>>runSequence: > IceLibgitLocalRepository>>cloneRepositoryFrom:branch: > IceRepositoryCreator>>createRepository > [ (IceRepositoryCreator new > url: remoteUrl; > subdirectory: repoPath; > branchName: self projectVersion; > createRepository) register ] in MCGitHubRepository>>getOrCreateIcebergRepository in Block: [ (IceRepositoryCreator new... > OrderedCollection(Collection)>>detect:ifFound:ifNone: > OrderedCollection(Collection)>>detect:ifNone: > MCGitHubRepository>>getOrCreateIcebergRepository > IceGithubRepositoryType>>mcRepository > Iceberg class>>mcRepositoryFor: > [ :cl | > (cl enableMetacelloIntegration > and: [ IceMetacelloRepositoryType canHandleType: type ]) > ifTrue: [ ^ cl mcRepositoryFor: aRepositorySpec description ] ] in MetacelloPharo30Platform(MetacelloPharoCommonPlatform)>>createRepository: in Block: [ :cl | ... > BlockClosure>>cull: > SystemDictionary(Dictionary)>>at:ifPresent: > SmalltalkImage>>at:ifPresent: > MetacelloPharo30Platform(MetacelloPharoCommonPlatform)>>createRepository: > MetacelloMCBaselineProject(MetacelloMCProject)>>createRepository: > MetacelloRepositorySpec>>createRepository > [ aSpec createRepository ] in [ :aSpec | > | description repo | > description := aSpec description. > (repo := repositories > detect: [ :rep | rep description = description ] > ifNone: [ aSpec createRepository ]) ~~ nil > ifTrue: [ repos add: repo ] ] in MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>repositoriesFrom:ignoreOverrides: in Block: [ aSpec createRepository ] > Array(Collection)>>detect:ifFound:ifNone: > Array(Collection)>>detect:ifNone: > [ :aSpec | > | description repo | > description := aSpec description. > (repo := repositories > detect: [ :rep | rep description = description ] > ifNone: [ aSpec createRepository ]) ~~ nil > ifTrue: [ repos add: repo ] ] in MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>repositoriesFrom:ignoreOverrides: in Block: [ :aSpec | ...

April 12, 2017

Re: [Pharo-dev] Please, test our 64bits builds

by Denis Kudriashov

PharmIDE works fine. But both images should has same bits 2017-04-12 16:44 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hello list, > > We are approaching to release and one big thing of this one is the 64bits > supports for Pharo (limited, since there is still not support for Windows, > but it will arrive, eventually ;) ) > I asked you to test a couple of months ago but now we are in better shape > to do it. > > - VM and image are getting more and more stable and crashes shouldnât > happen (but thatâs why I want you to test: to discover possible > bugs/crashes) > - I made 64bits a zeroconf citizen: http://get.pharo.org/64 > > Now, you can test it by just doing: > > curl get.pharo.org/64/60+vmLatest | bash > > (In linux or mac, remember it will not work for Windows) > > thanks! > Esteban > > >

April 12, 2017

Alien osVersion is not defined. Pharo 5

by nacho

Hi! I've been trying to run some examples from Alien. It seems that the method 'osVersion' is not defined anymore and that method is used in: Allien class>>libcName I guess it was a method that was removed from SmalltalkImage. Any work around? Thanks! Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Alien-osVersion-is-not-defined-Pharo-5-tp4941906.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 12, 2017

Re: [Pharo-dev] Please, test our 64bits builds

by Pavel Krivanek

- Iceberg commits do not work (known issue) - "OSWindowWorldMorph new open" does not work but it seems to do not work now on 32 bits too :-( - Roassal and Moose works well - when I did a RefshHunter snapshot of the image with Moose, saved the image and tried to create a new RefsHunter snapshot for generating of a large image, I got VM crashes. I can imagine that it is related to some obsolete FFI objects that are referenced by the RH snapshot from the previous session. -- Pavel 2017-04-12 16:44 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hello list, > > We are approaching to release and one big thing of this one is the 64bits > supports for Pharo (limited, since there is still not support for Windows, > but it will arrive, eventually ;) ) > I asked you to test a couple of months ago but now we are in better shape > to do it. > > - VM and image are getting more and more stable and crashes shouldnât > happen (but thatâs why I want you to test: to discover possible > bugs/crashes) > - I made 64bits a zeroconf citizen: http://get.pharo.org/64 > > Now, you can test it by just doing: > > curl get.pharo.org/64/60+vmLatest | bash > > (In linux or mac, remember it will not work for Windows) > > thanks! > Esteban > > >

April 12, 2017

Re: [Pharo-dev] Please, test our 64bits builds

by Alistair Grant

Hi Esteban, On Wed, Apr 12, 2017 at 04:44:51PM +0200, Esteban Lorenzano wrote: > Hello list, > > We are approaching to release and one big thing of this one is the > 64bits supports for Pharo (limited, since there is still not support > for Windows, but it will arrive, eventually ;) ) I asked you to test a > couple of months ago but now we are in better shape to do it. > > - VM and image are getting more and more stable and crashes > shouldn???t happen (but that???s why I want you to test: to discover > possible bugs/crashes) - I made 64bits a zeroconf citizen: > http://get.pharo.org/64 > > Now, you can test it by just doing: > > curl get.pharo.org/64/60+vmLatest | bash (In linux or mac, remember it > will not work for Windows) I'm getting: LGit_GIT_ERROR: no error message set by libgit2 (full stack below) while executing: Metacello new githubUser: 'pharophile' project: 'TilingWindowManager' commitish: 'master' path: 'packages'; baseline: 'TilingWindowManager'; onWarningLog; load. Checking that libgit2.so is OK produces: $ ldd libgit2.so ./libgit2.so: /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libssl.so.1.0.0: no version information available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4) ./libgit2.so: /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libssl.so.1.0.0: no version information available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4) ./libgit2.so: /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libssl.so.1.0.0: no version information available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4) ./libgit2.so: /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libcrypto.so.1.0.0: no version information available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4) linux-vdso.so.1 => (0x00007ffde370e000) libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f3b11727000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3b1150d000) libssl.so.1.0.0 => /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libssl.so.1.0.0 (0x00007f3b1129c000) libcrypto.so.1.0.0 => /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libcrypto.so.1.0.0 (0x00007f3b10ebf000) libssh2.so.1 => /dev/shm/p6/pharo-vm/lib/pharo/5.0-201704120850/libssh2.so.1 (0x00007f3b10c86000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3b10a7d000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3b10860000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3b10497000) libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x00007f3b10263000) librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f3b10047000) libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f3b0fdfd000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f3b0fbed000) libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f3b0f99c000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3b0f798000) /lib64/ld-linux-x86-64.so.2 (0x0000561a2abc3000) libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f3b0f467000) libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f3b0f234000) libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f3b0effd000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f3b0ed7d000) libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f3b0eaab000) libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f3b0e87b000) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f3b0e677000) libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f3b0e46c000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f3b0e250000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f3b0e035000) libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f3b0ddf4000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f3b0db8f000) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f3b0d97c000) libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f3b0d778000) libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f3b0d56e000) libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f3b0d2e4000) libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f3b0d041000) libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f3b0ce0e000) libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007f3b0cbf8000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f3b0c9ef000) libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007f3b0c7c6000) libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f3b0c5b7000) libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f3b0c36b000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f3b0c096000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f3b0be5e000) The first few lines look dodgy to me. Searching on google (admittedly briefly) it wasn't clear to me whether this is a fatal error or just a warning. Most of the responses suggest recompiling with matching versions, symbols, etc. Is there something else you'd like me to try? I can have a go at compiling if you think it will help. Cheers, Alistair LGitReturnCodeEnum>>handleLGitReturnCode LGitRepository(LGitExternalObject)>>withReturnHandlerDo: LGitRepository>>clone:options:to: LGitRepository>>clone:options: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self checkInitialized.... [ activeProcess psValueAt: index put: anObject. aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... BlockClosure>>ensure: LGitActionSequence(DynamicVariable)>>value:during: LGitActionSequence class(DynamicVariable class)>>value:during: LGitGlobal class>>runSequence: IceLibgitLocalRepository>>cloneRepositoryFrom:branch: IceRepositoryCreator>>createRepository [ (IceRepositoryCreator new url: remoteUrl; subdirectory: repoPath; branchName: self projectVersion; createRepository) register ] in MCGitHubRepository>>getOrCreateIcebergRepository in Block: [ (IceRepositoryCreator new... OrderedCollection(Collection)>>detect:ifFound:ifNone: OrderedCollection(Collection)>>detect:ifNone: MCGitHubRepository>>getOrCreateIcebergRepository IceGithubRepositoryType>>mcRepository Iceberg class>>mcRepositoryFor: [ :cl | (cl enableMetacelloIntegration and: [ IceMetacelloRepositoryType canHandleType: type ]) ifTrue: [ ^ cl mcRepositoryFor: aRepositorySpec description ] ] in MetacelloPharo30Platform(MetacelloPharoCommonPlatform)>>createRepository: in Block: [ :cl | ... BlockClosure>>cull: SystemDictionary(Dictionary)>>at:ifPresent: SmalltalkImage>>at:ifPresent: MetacelloPharo30Platform(MetacelloPharoCommonPlatform)>>createRepository: MetacelloMCBaselineProject(MetacelloMCProject)>>createRepository: MetacelloRepositorySpec>>createRepository [ aSpec createRepository ] in [ :aSpec | | description repo | description := aSpec description. (repo := repositories detect: [ :rep | rep description = description ] ifNone: [ aSpec createRepository ]) ~~ nil ifTrue: [ repos add: repo ] ] in MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>repositoriesFrom:ignoreOverrides: in Block: [ aSpec createRepository ] Array(Collection)>>detect:ifFound:ifNone: Array(Collection)>>detect:ifNone: [ :aSpec | | description repo | description := aSpec description. (repo := repositories detect: [ :rep | rep description = description ] ifNone: [ aSpec createRepository ]) ~~ nil ifTrue: [ repos add: repo ] ] in MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>repositoriesFrom:ignoreOverrides: in Block: [ :aSpec | ...

April 12, 2017

Please, test our 64bits builds

by Esteban Lorenzano

Hello list, We are approaching to release and one big thing of this one is the 64bits supports for Pharo (limited, since there is still not support for Windows, but it will arrive, eventually ;) ) I asked you to test a couple of months ago but now we are in better shape to do it. - VM and image are getting more and more stable and crashes shouldnât happen (but thatâs why I want you to test: to discover possible bugs/crashes) - I made 64bits a zeroconf citizen: http://get.pharo.org/64 Now, you can test it by just doing: curl get.pharo.org/64/60+vmLatest | bash (In linux or mac, remember it will not work for Windows) thanks! Esteban

April 12, 2017

Re: [Pharo-dev] [Ann] Commander. Command pattern library

by Denis Kudriashov

2017-04-12 15:27 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > I see. But why not to let the class subscribe to what it needs? > Maybe something like: > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Command subclass: #ClyShowClassRefCommand > > I guess you mean: > ClyShowClassRefCommand class>>registerFor: aCommandActivator > aCommandActivator add: self for: *ClyClassSystemBrowserContext*. > aCommandActivator add: self for: *ClyMethodBrowserContext*. > How different applications will extend such registration? Probably they will need multiple version of #registerFor:. And system will need to find them somehow. For example by pragma. No?

April 12, 2017

Re: [Pharo-dev] [Ann] Commander. Command pattern library

by Alexandre Bergel

I see. But why not to let the class subscribe to what it needs? Maybe something like: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Command subclass: #ClyShowClassRefCommand ClyShowClassRefCommand class>>registerFor: aCommandActivator aCommandActivator add: self for: ClyButtonToolbarGroup. aCommandActivator add: self for: ClyBrowserContext. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This is just a suggestion. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Apr 12, 2017, at 6:54 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-04-12 0:28 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: > I would imagine that your activatorClass can lookup the command simply as: > > PackageCommand allSubclasses select: [ :c | c isEnabledFor: â¦ ] > > This approach restricts command implementation and queries to single hierarchy which is not scale. > For example in Calypso there is ShowClassRefsCommand which is shown as toolbar button in both system and method browsers. But this command is in ClassCommand hierarchy because it operates on collection of classes. > We can lookup both MethodCommands and ClassCommands in method browser. But then we will have a lot of commands which we do not need in method browser. > > Another example is "browse" command which is accessed by cmd+b and from context menu of any browser pane. > > Here is how they all connected to Calypso browsers: > > ClyShowClassRefCommand class>>systemBrowserToolbarActivator > <commandActivator> > ^ClyToolbarCommandActivator byItemOf: ClyButtonToolbarGroup for: ClyClassSystemBrowserContext > > ClyShowClassRefCommand class>methodBrowserToolbarActivator > <commandActivator> > ^ClyToolbarCommandActivator byItemOf: ClyButtonToolbarGroup for: ClyMethodBrowserContext > > ClySpawnSystemBrowserCommand class>>browserShortcutActivator > <commandActivator> > ^CmdShortcutCommandActivator by: $b meta for: ClyBrowserContext > > ClySpawnSystemBrowserCommand class>>browserMenuActivator > <commandActivator> > ^CmdContextMenuCommandActivator byRootGroupItemFor: ClyBrowserContext > > (ClyBrowserContext is superclass of any Calypso browser contexts)

April 12, 2017