March 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #656: 21505-update-README-md [skip ci]

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #656 was: SUCCESS. The Pull Request #1032 was integrated: "21505-update-README-md [skip ci]" Pull request url: https://github.com/pharo-project/pharo/pull/1032 Issue Url: https://pharo.fogbugz.com/f/cases/21505 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 6, 2018

[Pharo 7.0-dev] Build #655: 21474 More cleanups in Compression-Tests

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #655 was: SUCCESS. The Pull Request #1009 was integrated: "21474 More cleanups in Compression-Tests" Pull request url: https://github.com/pharo-project/pharo/pull/1009 Issue Url: https://pharo.fogbugz.com/f/cases/21474 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 6, 2018

Re: [Pharo-dev] Pharo6 with Ubuntu and OSSubprocess/threaded heartbeat crashes and problems

by Sabine Manaa

Hi, I can report the following: The problem with the Buffer overflow remains also with OSProcess. Also with the normal vm (https://get.pharo.org ). Summary: I have buffer overflow crashes with my application on Linux. The same code runs without problems on MacOS and on Windows. I have the same test data/database and do exactly the same. The problem occurs only after calling several times OSProcess/OSSubprocess. This is the reason why I first had a suspicion that OSSubprocess is responsible for the crashes. Can anyone tell me how to proceed to find the reason for the buffer overflow? There is no PharoDebug.log Help is very appreciated! This is the message when terminating: root@Pharo_ubuntu_16:/spf/build# ./pharo Pharo-Productive-SPF.image --no-quit SmalltalkImageInstanceID class>>startUp*** buffer overflow detected ***: /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo terminated ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x67377)[0xf75b9377] /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x68)[0xf7649708] /lib/i386-linux-gnu/libc.so.6(+0xf58f8)[0xf76478f8] /lib/i386-linux-gnu/libc.so.6(+0xf75fa)[0xf76495fa] /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo( aioEnable+0x31)[0x80c9811] /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo[0x81215ee] [0x90010e0] [0x90ad2d0] [0x90db8b4] [0x90ad24a] [0x900be6b] [0x900b04d] [0x9007a3e] [0x9004247] [0x9004572] [0x9001020] [0xa98c524] [0xb1755db] [0x9003efc] [0x9001020] [0xdcb558c] [0xb0d4d95] [0x9000ff0] ======= Memory map: ======== 08048000-08164000 r-xp 00000000 00:1b 1183256 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo 08164000-08165000 r--p 0011b000 00:1b 1183256 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo 08165000-08170000 rw-p 0011c000 00:1b 1183256 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo 08170000-081a7000 rw-p 00000000 00:00 0 08fdd000-08ffe000 rw-p 00000000 00:00 0 [heap] 09000000-09100000 rwxp 00000000 00:00 0 09100000-11200000 rw-p 00000000 00:00 0 f552e000-f554a000 r-xp 00000000 00:1b 8244 /lib/i386-linux-gnu/libgcc_s.so.1 f554a000-f554b000 rw-p 0001b000 00:1b 8244 /lib/i386-linux-gnu/libgcc_s.so.1 f554b000-f684c000 rw-p 00000000 00:00 0 f684c000-f684f000 r-xp 00000000 00:1b 1183242 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/JPEGReaderPlugin.so f684f000-f6850000 r--p 00002000 00:1b 1183242 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/JPEGReaderPlugin.so f6850000-f6851000 rw-p 00003000 00:1b 1183242 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/JPEGReaderPlugin.so f6851000-f68b2000 r-xp 00000000 00:1b 1183230 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libssl.so.1.0.0 f68b2000-f68b3000 ---p 00061000 00:1b 1183230 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libssl.so.1.0.0 f68b3000-f68b5000 r--p 00061000 00:1b 1183230 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libssl.so.1.0.0 f68b5000-f68b9000 rw-p 00063000 00:1b 1183230 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libssl.so.1.0.0 f68b9000-f6a7b000 r-xp 00000000 00:1b 1183239 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 f6a7b000-f6a7c000 ---p 001c2000 00:1b 1183239 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 f6a7c000-f6a8c000 r--p 001c2000 00:1b 1183239 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 f6a8c000-f6a93000 rw-p 001d2000 00:1b 1183239 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 f6a93000-f6a96000 rw-p 00000000 00:00 0 f6a96000-f6a9b000 r-xp 00000000 00:1b 1183249 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/SqueakSSL.so f6a9b000-f6a9c000 r--p 00004000 00:1b 1183249 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/SqueakSSL.so f6a9c000-f6a9d000 rw-p 00005000 00:1b 1183249 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/SqueakSSL.so f6a9d000-f6ab1000 r-xp 00000000 00:1b 7925 /lib/i386-linux-gnu/libresolv-2.23.so f6ab1000-f6ab2000 ---p 00014000 00:1b 7925 /lib/i386-linux-gnu/libresolv-2.23.so f6ab2000-f6ab3000 r--p 00014000 00:1b 7925 /lib/i386-linux-gnu/libresolv-2.23.so f6ab3000-f6ab4000 rw-p 00015000 00:1b 7925 /lib/i386-linux-gnu/libresolv-2.23.so f6ab4000-f6ab6000 rw-p 00000000 00:00 0 f6ab6000-f6abb000 r-xp 00000000 00:1b 7931 /lib/i386-linux-gnu/libnss_dns-2.23.so f6abb000-f6abc000 r--p 00004000 00:1b 7931 /lib/i386-linux-gnu/libnss_dns-2.23.so f6abc000-f6abd000 rw-p 00005000 00:1b 7931 /lib/i386-linux-gnu/libnss_dns-2.23.so f6abd000-f6c05000 rw-p 00000000 00:00 0 f6c05000-f6c2e000 r-xp 00000000 00:1b 8373 /lib/i386-linux-gnu/libpng12.so.0.54.0 f6c2e000-f6c2f000 r--p 00028000 00:1b 8373 /lib/i386-linux-gnu/libpng12.so.0.54.0 f6c2f000-f6c30000 rw-p 00029000 00:1b 8373 /lib/i386-linux-gnu/libpng12.so.0.54.0 f6c30000-f6c49000 r-xp 00000000 00:1b 8362 /lib/i386-linux-gnu/libz.so.1.2.8 f6c49000-f6c4a000 r--p 00018000 00:1b 8362 /lib/i386-linux-gnu/libz.so.1.2.8 f6c4a000-f6c4b000 rw-p 00019000 00:1b 8362 /lib/i386-linux-gnu/libz.so.1.2.8 f6c4b000-f6cf6000 r-xp 00000000 00:1b 8395 /usr/lib/i386-linux-gnu/libfreetype.so.6.12.1 f6cf6000-f6cfa000 r--p 000aa000 00:1b 8395 /usr/lib/i386-linux-gnu/libfreetype.so.6.12.1 f6cfa000-f6cfb000 rw-p 000ae000 00:1b 8395 /usr/lib/i386-linux-gnu/libfreetype.so.6.12.1 f6cfb000-f6d02000 r-xp 00000000 00:1b 1183229 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so f6d02000-f6d03000 r--p 00006000 00:1b 1183229 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so f6d03000-f6d04000 rw-p 00007000 00:1b 1183229 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so f6d04000-f6d0f000 r-xp 00000000 00:1b 7934 /lib/i386-linux-gnu/libnss_files-2.23.so f6d0f000-f6d10000 r--p 0000a000 00:1b 7934 /lib/i386-linux-gnu/libnss_files-2.23.so f6d10000-f6d11000 rw-p 0000b000 00:1b 7934 /lib/i386-linux-gnu/libnss_files-2.23.so f6d11000-f6d38000 rw-p 00000000 00:00 0 f6d38000-f6d39000 ---p 00000000 00:00 0 f6d39000-f7539000 rw-p 00000000 00:00 0 [stack:21188] f7539000-f753b000 r-xp 00000000 00:1b 7968 /usr/lib/i386-linux-gnu/gconv/MACINTOSH.so f753b000-f753c000 r--p 00001000 00:1b 7968 /usr/lib/i386-linux-gnu/gconv/MACINTOSH.so f753c000-f753d000 rw-p 00002000 00:1b 7968 /usr/lib/i386-linux-gnu/gconv/MACINTOSH.so f753d000-f7544000 r--s 00000000 00:1b 7977 /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache f7544000-f754a000 r-xp 00000000 00:1b 1183240 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-sound-OSS.so f754a000-f754b000 r--p 00005000 00:1b 1183240 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-sound-OSS.so f754b000-f754c000 rw-p 00006000 00:1b 1183240 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-sound-OSS.so f754c000-f754e000 r-xp 00000000 00:1b 1183257 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-display-null.so f754e000-f754f000 r--p 00001000 00:1b 1183257 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-display-null.so f754f000-f7550000 rw-p 00002000 00:1b 1183257 /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-display-null.so f7550000-f7552000 rw-p 00000000 00:00 0 f7552000-f7702000 r-xp 00000000 00:1b 7921 /lib/i386-linux-gnu/libc-2.23.so f7702000-f7704000 r--p 001af000 00:1b 7921 /lib/i386-linux-gnu/libc-2.23.so f7704000-f7705000 rw-p 001b1000 00:1b 7921 /lib/i386-linux-gnu/libc-2.23.so f7705000-f7708000 rw-p 00000000 00:00 0 f7708000-f775b000 r-xp 00000000 00:1b 7917 /lib/i386-linux-gnu/libm-2.23.so f775b000-f775c000 r--p 00052000 00:1b 7917 /lib/i386-linux-gnu/libm-2.23.so f775c000-f775d000 rw-p 00053000 00:1b 7917 /lib/i386-linux-gnu/libm-2.23.so f775d000-f7776000 r-xp 00000000 00:1b 7920 /lib/i386-linux-gnu/libpthread-2.23.so f7776000-f7777000 r--p 00018000 00:1b 7920 /lib/i386-linux-gnu/libpthread-2.23.so f7777000-f7778000 rw-p 00019000 00:1b 7920 /lib/i386-linux-gnu/libpthread-2.23.so f7778000-f777a000 rw-p 00000000 00:00 0 f777a000-f777d000 r-xp 00000000 00:1b 7923 /lib/i386-linux-gnu/libdl-2.23.so f777d000-f777e000 r--p 00002000 00:1b 7923 /lib/i386-linux-gnu/libdl-2.23.so f777e000-f777f000 rw-p 00003000 00:1b 7923 /lib/i386-linux-gnu/libdl-2.23.so f777f000-f7780000 rw-p 00000000 00:00 0 f7780000-f7781000 r-xp 00000000 00:00 0 [vdso] f7781000-f77a4000 r-xp 00000000 00:1b 7919 /lib/i386-linux-gnu/ld-2.23.so f77a4000-f77a5000 r--p 00022000 00:1b 7919 /lib/i386-linux-gnu/ld-2.23.so f77a5000-f77a6000 rw-p 00023000 00:1b 7919 /lib/i386-linux-gnu/ld-2.23.so ffc55000-ffcd1000 rw-p 00000000 00:00 0 [stack] ./pharo: line 11: 14639 Aborted "$DIR"/"pharo-vm/pharo" --nodisplay "$@" 2018-03-05 17:38 GMT+01:00 Sabine Manaa <manaa.sabine(a)gmail.com>: > Hi Mariano and Thierry, > > I load on Pharo 32 bit with: > > spec > baseline: 'OSSubprocess' > with: [ spec > className: 'BaselineOfOSSubprocess'; > repository: 'github://marianopeck/OSSubprocess:v0.2.5/repository' ]; > import: 'OSSubprocess' > > Tomorrow I will try to load on Pharo7 and try to use OSProcess and see if > it still crashes. > > Sabine > > > > > > 2018-03-05 17:23 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> Hi Sabine, >> >> Which OSSubprocess version are you using? If are using ConfigurationOf to >> load it, then please tell me which version from there. >> If you are using from baseline, tell me if you are grabbing master, a >> given tag , a given commit, etc. >> I will assume it is Pharo 32 bits rigth? >> >> I will continue with a more detailed answer once you get back to me with >> above questions. >> >> Cheers, >> >> >> >> >> On Mon, Mar 5, 2018 at 1:14 PM, Sabine Manaa <manaa.sabine(a)gmail.com> >> wrote: >> >>> Hi Alistair, >>> >>> thank you! The message (pthread_setschedparam failed: Operation not >>> permitted) is gone now. So Question 1 is solved. >>> >>> But the crashes (Question 2) are remaining. After calling several >>> OSSubprocess commands, Pharo crashes without PharoDebug.log. >>> >>> Anyone having an Idea what I could do? >>> >>> Sabine >>> >>> >>> >>> >>> 2018-03-05 13:07 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: >>> >>>> Hi Sabine, >>>> >>>> The docket container will need to be privileged to adjust thread >>>> priority. >>>> >>>> >>>> Cheers, >>>> Alistair >>>> (on phone) >>>> >>>> On 5 Mar. 2018 12:44, "Sabine Manaa" <manaa.sabine(a)gmail.com> wrote: >>>> >>>> We want to run Pharo6 with Ubuntu 16.04 Linux (in a Docker Image) and >>>> use >>>> OSSubprocess. >>>> >>>> For this, we use this vm: https://get.pharo.org/61+vmT >>>> >>>> [1] tells me: "If you are installing under Linux, then you must use a >>>> threaded heartbeat VM" >>>> >>>> We also created a file /etc/security/limits.d/pharo.conf and put the >>>> parameters in like described in the message [2] when startup. Also we >>>> log >>>> out and in. >>>> >>>> Question 1: the message (pthread_setschedparam failed: Operation not >>>> permitted) comes again to the console each time we use OSSubprocess. As >>>> far >>>> as I understand, it should disappear. Does this mean, that we did not >>>> edit >>>> the pharo.conf correctly? >>>> >>>> Question 2: after several uses of OSSubprocess within our application, >>>> Pharo >>>> crashes (no PharoDebug.log) with the following messages [3]. >>>> How can we avoid this, what are we doing wrong? >>>> >>>> Question 3: sometimes (!) when we load (exactly the same code loaded >>>> with a >>>> script), we also get a crash, see [4]. Bug? wrong vm? >>>> >>>> I am unhappy with this and it takes a lot of time. What are we doing >>>> wrong? >>>> We want to run Pharo6 with OSSubprocess in Linux within a docker image >>>> for >>>> our staging environment. >>>> >>>> Help very welcome :-) >>>> Sabine >>>> >>>> >>>> [1]https://github.com/marianopeck/OSSubprocess >>>> [2](https://github.com/OpenSmalltalk/opensmalltalk-vm/releas >>>> es/tag/r3732#linux) >>>> >>>> [3]crash message >>>> *** buffer overflow detected ***: >>>> /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo terminated >>>> ======= Backtrace: ========= >>>> /lib/i386-linux-gnu/libc.so.6(+0x67377)[0xf75f3377] >>>> /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x68)[0xf7683708] >>>> /lib/i386-linux-gnu/libc.so.6(+0xf58f8)[0xf76818f8] >>>> /lib/i386-linux-gnu/libc.so.6(+0xf75fa)[0xf76835fa] >>>> /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo(aioEnab >>>> le+0x31)[0x80c9811] >>>> /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo[0x81215ee] >>>> [0xa1010e0] >>>> [0xa1c2bb8] >>>> [0xa15f50c] >>>> ....a lot more >>>> >>>> >>>> >>>> [4] PharoDebug.log >>>> HERE_BE_DRAGONS_HERE >>>> KeyNotFound: key #arg1 not found in Dictionary >>>> 5 March 2018 11:31:51.792142 am >>>> >>>> VM: unix - i686 - linux-gnu - CoInterpreter VMMaker.oscog-eem.2254 uuid: >>>> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 >>>> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >>>> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 >>>> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >>>> $ >>>> Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 >>>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >>>> >>>> Image: Pharo6.0 [Latest update: #60536] >>>> >>>> Dictionary>>errorKeyNotFound: >>>> Receiver: a Dictionary(#arg3->1 #tmp2->2 ) >>>> Arguments and temporary variables: >>>> aKey: #arg1 >>>> Receiver's instance variables: >>>> tally: 2 >>>> array: {nil. nil. #arg3->1. #tmp2->2. nil} >>>> >>>> >>>> [ self errorKeyNotFound: key ] in Dictionary>>at: >>>> Receiver: a Dictionary(#arg3->1 #tmp2->2 ) >>>> Arguments and temporary variables: >>>> key: #arg1 >>>> Receiver's instance variables: >>>> tally: 2 >>>> array: {nil. nil. #arg3->1. #tmp2->2. nil} >>>> >>>> >>>> Dictionary>>at:ifAbsent: >>>> Receiver: a Dictionary(#arg3->1 #tmp2->2 ) >>>> Arguments and temporary variables: >>>> arg1: #arg1 >>>> arg2: [ self errorKeyNotFound: key ] >>>> tmp1: nil >>>> Receiver's instance variables: >>>> tally: 2 >>>> array: {nil. nil. #arg3->1. #tmp2->2. nil} >>>> >>>> >>>> Dictionary>>at: >>>> Receiver: a Dictionary(#arg3->1 #tmp2->2 ) >>>> Arguments and temporary variables: >>>> key: #arg1 >>>> Receiver's instance variables: >>>> tally: 2 >>>> array: {nil. nil. #arg3->1. #tmp2->2. nil} >>>> >>>> >>>> IRPushClosureCopy>>indexForVarNamed: >>>> Receiver: pushClosureCopyCopiedValues: #() args: #(#arg3) >>>> Arguments and temporary variables: >>>> aName: #arg1 >>>> Receiver's instance variables: >>>> sourceNode: RBBlockNode([ :arg3 | >>>> | tmp2 | >>>> tmp2 := arg3. >>>> tmp2 >>>> nextPutAll: arg...etc... >>>> bytecodeIndex: nil >>>> sequence: an IRSequence (1) >>>> destination: an IRSequence (3) >>>> successor: nil >>>> numArgs: nil >>>> blockSequence: an IRSequence (2) >>>> tempMap: a Dictionary(#arg3->1 #tmp2->2 ) >>>> copiedValues: #() >>>> lastBlockSequence: an IRSequence (2) >>>> arguments: #(#arg3) >>>> >>>> >>>> IRTranslatorV2>>visitPushTemp: >>>> Receiver: an IRTranslatorV2 >>>> Arguments and temporary variables: >>>> tmp: pushTemp: #arg1 >>>> Receiver's instance variables: >>>> gen: an IRBytecodeGenerator >>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>> #() args: #(#arg3) an >>>> IRMeth...etc... >>>> trailer: a CompiledMethodTrailer >>>> tempVectorStack: a Stack() >>>> compilationContext: a CompilationContext >>>> >>>> >>>> IRPushTemp>>accept: >>>> Receiver: pushTemp: #arg1 >>>> Arguments and temporary variables: >>>> aVisitor: an IRTranslatorV2 >>>> Receiver's instance variables: >>>> sourceNode: RBArgumentNode(arg1) >>>> bytecodeIndex: nil >>>> sequence: an IRSequence (2) >>>> name: #arg1 >>>> >>>> >>>> IRTranslatorV2(IRVisitor)>>visitNode: >>>> Receiver: an IRTranslatorV2 >>>> Arguments and temporary variables: >>>> elem: pushTemp: #arg1 >>>> Receiver's instance variables: >>>> gen: an IRBytecodeGenerator >>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>> #() args: #(#arg3) an >>>> IRMeth...etc... >>>> trailer: a CompiledMethodTrailer >>>> tempVectorStack: a Stack() >>>> compilationContext: a CompilationContext >>>> >>>> >>>> IRTranslatorV2>>visitInstruction: >>>> Receiver: an IRTranslatorV2 >>>> Arguments and temporary variables: >>>> instr: pushTemp: #arg1 >>>> Receiver's instance variables: >>>> gen: an IRBytecodeGenerator >>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>> #() args: #(#arg3) an >>>> IRMeth...etc... >>>> trailer: a CompiledMethodTrailer >>>> tempVectorStack: a Stack() >>>> compilationContext: a CompilationContext >>>> >>>> >>>> [ :arg2 | self visitInstruction: arg2 ] in >>>> IRTranslatorV2(IRVisitor)>>visitSequence: >>>> Receiver: an IRTranslatorV2 >>>> Arguments and temporary variables: >>>> arg1: an IRSequence (2) >>>> arg2: pushTemp: #arg1 >>>> Receiver's instance variables: >>>> gen: an IRBytecodeGenerator >>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>> #() args: #(#arg3) an >>>> IRMeth...etc... >>>> trailer: a CompiledMethodTrailer >>>> tempVectorStack: a Stack() >>>> compilationContext: a CompilationContext >>>> >>>> >>>> OrderedCollection>>do: >>>> Receiver: an OrderedCollection(pushTemp: #arg3 popIntoTemp: >>>> #tmp2 pushTemp: >>>> #tmp2 pushDup pushTemp: ...etc... >>>> Arguments and temporary variables: >>>> <<error during printing> >>>> Receiver's instance variables: >>>> array: an Array(pushTemp: #arg3 popIntoTemp: #tmp2 >>>> pushTemp: #tmp2 >>>> pushDup push...etc... >>>> firstIndex: 1 >>>> lastIndex: 25 >>>> >>>> >>>> IRSequence>>do: >>>> Receiver: an IRSequence (2) >>>> Arguments and temporary variables: >>>> aBlock: [ :arg2 | self visitInstruction: arg2 ] >>>> Receiver's instance variables: >>>> sequence: an OrderedCollection(pushTemp: #arg3 >>>> popIntoTemp: #tmp2 >>>> pushTemp: #tm...etc... >>>> orderNumber: 2 >>>> method: an IRMethod >>>> >>>> >>>> IRTranslatorV2(IRVisitor)>>visitSequence: >>>> Receiver: an IRTranslatorV2 >>>> Arguments and temporary variables: >>>> arg1: an IRSequence (2) >>>> Receiver's instance variables: >>>> gen: an IRBytecodeGenerator >>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>> #() args: #(#arg3) an >>>> IRMeth...etc... >>>> trailer: a CompiledMethodTrailer >>>> tempVectorStack: a Stack() >>>> compilationContext: a CompilationContext >>>> >>>> >>>> IRTranslatorV2>>visitSequence: >>>> Receiver: an IRTranslatorV2 >>>> Arguments and temporary variables: >>>> instructionSequence: an IRSequence (2) >>>> Receiver's instance variables: >>>> gen: an IRBytecodeGenerator >>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>> #() args: #(#arg3) an >>>> IRMeth...etc... >>>> trailer: a CompiledMethodTrailer >>>> tempVectorStack: a Stack() >>>> compilationContext: a CompilationContext >>>> >>>> >>>> IRSequence>>accept: >>>> Receiver: an IRSequence (2) >>>> Arguments and temporary variables: >>>> aVisitor: an IRTranslatorV2 >>>> Receiver's instance variables: >>>> sequence: an OrderedCollection(pushTemp: #arg3 >>>> popIntoTemp: #tmp2 >>>> pushTemp: #tm...etc... >>>> orderNumber: 2 >>>> method: an IRMethod >>>> >>>> >>>> IRTranslatorV2(IRVisitor)>>visitNode: >>>> Receiver: an IRTranslatorV2 >>>> Arguments and temporary variables: >>>> elem: an IRSequence (2) >>>> Receiver's instance variables: >>>> gen: an IRBytecodeGenerator >>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>> #() args: #(#arg3) an >>>> IRMeth...etc... >>>> trailer: a CompiledMethodTrailer >>>> tempVectorStack: a Stack() >>>> compilationContext: a CompilationContext >>>> >>>> >>>> [ :arg2 | self visitNode: arg2 ] in IRTranslatorV2(IRVisitor)>>vis >>>> itNodes: >>>> Receiver: an IRTranslatorV2 >>>> Arguments and temporary variables: >>>> arg1: a SortedCollection(an IRSequence (1) an >>>> IRSequence (2) an >>>> IRSequence (3) ...etc... >>>> arg2: an IRSequence (2) >>>> Receiver's instance variables: >>>> gen: an IRBytecodeGenerator >>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>> #() args: #(#arg3) an >>>> IRMeth...etc... >>>> trailer: a CompiledMethodTrailer >>>> tempVectorStack: a Stack() >>>> compilationContext: a CompilationContext >>>> >>>> >>>> SortedCollection(OrderedCollection)>>do: >>>> Receiver: a SortedCollection(an IRSequence (1) an IRSequence >>>> (2) an >>>> IRSequence (3) an IRSequence (4)...etc... >>>> Arguments and temporary variables: >>>> <<error during printing> >>>> Receiver's instance variables: >>>> array: an Array(an IRSequence (1) an IRSequence (2) an >>>> IRSequence (3) an >>>> IRSequ...etc... >>>> firstIndex: 1 >>>> lastIndex: 7 >>>> sortBlock: [ :arg2 :arg3 | arg2 orderNumber <= >>>> arg3 orderNumber ] >>>> >>>> >>>> IRTranslatorV2(IRVisitor)>>visitNodes: >>>> Receiver: an IRTranslatorV2 >>>> Arguments and temporary variables: >>>> arg1: a SortedCollection(an IRSequence (1) an >>>> IRSequence (2) an >>>> IRSequence (3) ...etc... >>>> Receiver's instance variables: >>>> gen: an IRBytecodeGenerator >>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>> #() args: #(#arg3) an >>>> IRMeth...etc... >>>> trailer: a CompiledMethodTrailer >>>> tempVectorStack: a Stack() >>>> compilationContext: a CompilationContext >>>> >>>> >>>> IRTranslatorV2>>visitSequences: >>>> Receiver: an IRTranslatorV2 >>>> Arguments and temporary variables: >>>> arg1: a SortedCollection(an IRSequence (1) an >>>> IRSequence (2) an >>>> IRSequence (3) ...etc... >>>> Receiver's instance variables: >>>> gen: an IRBytecodeGenerator >>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>> #() args: #(#arg3) an >>>> IRMeth...etc... >>>> trailer: a CompiledMethodTrailer >>>> tempVectorStack: a Stack() >>>> compilationContext: a CompilationContext >>>> >>>> >>>> IRTranslatorV2>>visitMethod: >>>> Receiver: an IRTranslatorV2 >>>> Arguments and temporary variables: >>>> anIr: an IRMethod >>>> Receiver's instance variables: >>>> gen: an IRBytecodeGenerator >>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>> #() args: #(#arg3) an >>>> IRMeth...etc... >>>> trailer: a CompiledMethodTrailer >>>> tempVectorStack: a Stack() >>>> compilationContext: a CompilationContext >>>> >>>> >>>> IRMethod>>accept: >>>> Receiver: an IRMethod >>>> Arguments and temporary variables: >>>> aVisitor: an IRTranslatorV2 >>>> Receiver's instance variables: >>>> sourceNode: logError: arg1 inContext: arg2 >>>> self >>>> logStdErrorDuring: [ :arg3 |...etc... >>>> startSequence: an IRSequence (1) >>>> numArgs: 2 >>>> properties: nil >>>> tempMap: a Dictionary(#arg1->1 #arg2->2 ) >>>> pragmas: an OrderedCollection() >>>> additionalLiterals: an OCLiteralSet(#ifNotNil:) >>>> compiledMethod: nil >>>> compilationContext: a CompilationContext >>>> irPrimitive: primitive 0 >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.ht >>>> ml >>>> >>>> >>>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

March 6, 2018

[Pharo 7.0-dev] Build #654: 21485 Use assert:equals: and other small cleanups in StringTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #654 was: SUCCESS. The Pull Request #1020 was integrated: "21485 Use assert:equals: and other small cleanups in StringTest" Pull request url: https://github.com/pharo-project/pharo/pull/1020 Issue Url: https://pharo.fogbugz.com/f/cases/21485 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 6, 2018

[ANN] 64 bits support preview

by Mariano Martinez Peck

Hi guys, Thanks for Guillermo Polito we now have 64 bits support for OSSubprocess. You can see the required changes in this PR [1]. I made a branch called `support64bits` so that you can help us test it even if CI said it was good [2]. If you do test it and come back to us with the results, please tell us which OS you used. To install from the branch: Metacello new configuration: 'OSSubprocess'; repository: 'github://marianopeck/OSSubprocess:support64bits/repository'; version: #stable; load. Roadmap: Current release is v0.2.5. So I will let that release for Pharo <= 5.0. I will make a new release with the Pharo 64 bits and call it v0.3. That release should be used for Pharo 6.x. Once v0.3 is out, I will make a new release v0.4 with some changes I wanted to do since a loooong time and its a small refactor to minimize OSSubprocess dependency on OSProcesses primitives (at VM side). This is thanks to Holger Freyther and Alistair Grant [3]. As that requires a new VM, then v0.4 should be used in Pharo >= 7.0. Cheers, [1] https://github.com/marianopeck/OSSubprocess/pull/30 [2] https://travis-ci.org/guillep/OSSubprocess/builds/349280174 [3] https://github.com/pharo-project/pharo-vm/pull/142 -- Mariano http://marianopeck.wordpress.com

March 6, 2018

[Pharo 7.0-dev] Build #653: 21482 Cleanup String>>endsWith:

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #653 was: SUCCESS. The Pull Request #1018 was integrated: "21482 Cleanup String>>endsWith:" Pull request url: https://github.com/pharo-project/pharo/pull/1018 Issue Url: https://pharo.fogbugz.com/f/cases/21482 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Dale Henrichs

On 03/05/2018 11:22 AM, Stephane Ducasse wrote: >> In an image where you want to use the dev_pharo7 for a project, you do a >> Metacello lock on github://xxxx/xxx:dev_pharo7/src BEFORE loading the >> project ... if there are multiple projects that need to all coordinate >> development then you follow the same convention and use a Metacello lock for >> each of the projects ... Executing expressions to lock projects is tedious >> to use and manage. > Do you have a text explaining what is a lock? > I do not understand the problems locks solve. The "Lock Command Reference" hopefully does the job[1]. Dale [1] https://github.com/Metacello/metacello/blob/master/docs/LockCommandReferenc…

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Stephane Ducasse

On Mon, Mar 5, 2018 at 8:07 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > On 03/05/2018 09:07 AM, Guillermo Polito wrote: >> >> On the other side, there is the fact that Metacello baselines are so far >> nice to describe release project dependencies, but they are not so nice to >> describe subprojects/development dependencies that may get edited along with >> the parent project. Kind of what we used to do with #bleedingEdge. I feel >> this is a complex problem, that not even SBT or maven that are there since >> years are capable of solving nicely... Tode and Iceberg metacello >> integration try to solve this problem by "ignoring the dependency and using >> the loaded repository" but this may not be successful either... > > > I have not been following this thread in detail, but this comment leads me > to believe that the issue that you guys are running into has to do with > trying to ongoing distributed development across multiple projects and > multiple platform versions ... > > If so then I think that the moral equivalent of #bleedingEdge should be a > branch structure along the lines of: > > master branch --- the project release that is known to work on all > supported platform versions. > dev_pharo6 --- the current #bleedingEdge for Pharo6.0 > dev_pharo7 --- the current #bleedingEdge for Pharo7.0 for Pharo master is the current released version and dev the bleeding edge > > In an image where you want to use the dev_pharo7 for a project, you do a > Metacello lock on github://xxxx/xxx:dev_pharo7/src BEFORE loading the > project ... if there are multiple projects that need to all coordinate > development then you follow the same convention and use a Metacello lock for > each of the projects ... Executing expressions to lock projects is tedious > to use and manage. Do you have a text explaining what is a lock? I do not understand the problems locks solve. > > In tODE I started using project entries[1] that are downloaded to disk and > shared by multiple images that allow a developer to specify what > branch/tag/commit they are interested in using ... each image that is > started up in a "cluster" uses the project entry to do a Metacello lock on > the project "automagically"... if there is a series of projects where the > developer needs to use dev_pharo6 they can arrange to edit the project entry > to reflect the proper branches for the set of projects that need special > _development_ treatment ... these .ston files can be shared amongst groups > of developers ... of course once the local clones of these projects are on > the local disk, then it is up to the developer (or a set of scripts) to > periodically update to the latest development version of each of the > projects ... > > To share a specific configuration of development git repos, you need to know > that SHA anyway, so the image can produce a collection of project entries > with the SHA of the commit and those project entries can be included in a > bug report ... > > For Rowan[2], I am using a "load specification"[3], which is a second > generation project entry .... the Rowan work is still evolving ... > > Anyway, I think that putting the control of what is being used for > development completely in the developers hands and avoiding the need to edit > baselines is a good thing ... and I think that the idea of having > specifications that are shared by a cluster of images is a good way to go > ... > > Dale > > [1] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside32.ston > [2] https://github.com/dalehenrich/Rowan > [3] https://github.com/dalehenrich/Rowan/blob/master/specs/Rowan.ston >

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Dale Henrichs

That's fine ... but then it should be a separate thread ... Dale On 03/05/2018 11:16 AM, Stephane Ducasse wrote: > Dale > > no private emails please. > > stef > > On Mon, Mar 5, 2018 at 6:57 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: >> Cyril, >> >> For development I tend to use Metacello locking instead of hard-wired >> dependencies in the BaselineOf and that works very well --- it completely >> avoids the need to edit a baseline for development purposes and this >> approach works really well for me ... perhaps we can discuss this in more >> detail in a separate thread or even private email? This all seems to be more >> complicated for you guys than has been my experience and of course you guys >> _appear_ to be completely ignoring the Metacello locking feature so I'm >> curious why ... >> >> Dale >> >> >> On 03/05/2018 08:02 AM, Cyril Ferlicot wrote: >> >> >> On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >>> >>> I still do not understand... Also I do not understand your usage of the >>> term "the merge". Can somebody give a **concrete** scenario? >>> >> I'll try >> For example the project MaterialDesignLite have two branches that are always >> here: >> - master >> - development >> Each commit on master is a stable release and end up with a tag as "v1.2.2". >> Since it's stable, BaselineOfMaterialDesignLite should depend only on fixed >> version of the dependencies. For example it should depend on >> MaterialDesignColor "v1.0.0". >> On the branch dev, we want to get the patches and possibly the minor >> versions of the dependencies automatically. In the baseline we then want to >> depend on MaterialDesignColor "v1.x.x". Thus, we follow the changes of >> MaterialDesignColor while it's not a major release. >> Because of this situation, BaselineOfMaterialDesignLite is different on the >> two branches. Later, if I want to merge development into master in order to >> release a new version, master will get the BaselineOfMaterialDesignLite with >> semantic versionning dependencies instead of the fixed dependencies. Before >> the release I'll need to change the Baseline to get fix dependencies once >> again. >> I hope I was clearer. :) >> >>> When you release a version, please do not move that version. You should >>> then create new versions, with new numbers and new code. But never touch old >>> versions with old numbers and old code. Like that I can download the same >>> old code using the same old number to get the old version whenever I want >>> :). >>> >>> You can try to do it with branches, tags, different repositories, or even >>> with zipfiles in mails. I don't care. Just don't modify releases and I'm >>> happy with it. >>> >>> >>> >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >>

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Dale Henrichs

Denis, See the "Lock Command Reference"[1] .. As I mention in a subsequent message I think that the best approach is to have meta specification for the configuration of a development environment that includes a spec for what should be loaded and this spec needs to be something that individual developers can customize for there local dev environment ... then the Metacello BaselineOf is used for production loading purposes and the load specification is used for customizing a particular development environment which may include a mix of additional projects that all _under development_ together ... Dale [1] https://github.com/Metacello/metacello/blob/master/docs/LockCommandReferenc… On 03/05/2018 10:18 AM, Denis Kudriashov wrote: > Hi Dale. > > Where to read about locking? > > 2018-03-05 18:57 GMT+01:00 Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>>: > > Cyril, > > For development I tend to use Metacello locking instead of > hard-wired dependencies in the BaselineOf and that works very well > --- it completely avoids the need to edit a baseline for > development purposes and this approach works really well for me > ... perhaps we can discuss this in more detail in a separate > thread or even private email? This all seems to be more > complicated for you guys than has been my experience and of course > you guys _appear_ to be completely ignoring the Metacello locking > feature so I'm curious why ... > > Dale > > > On 03/05/2018 08:02 AM, Cyril Ferlicot wrote: >> >> On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito >> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> >> wrote: >> >> >> I still do not understand... Also I do not understand your >> usage of the term "the merge". Can somebody give a >> **concrete** scenario? >> >> I'll try >> For example the project MaterialDesignLite have two branches that >> are always here: >> - master >> - development >> Each commit on master is a stable release and end up with a tag >> as "v1.2.2". Since it's stable, BaselineOfMaterialDesignLite >> should depend only on fixed version of the dependencies. For >> example it should depend on MaterialDesignColor "v1.0.0". >> On the branch dev, we want to get the patches and possibly the >> minor versions of the dependencies automatically. In the baseline >> we then want to depend on MaterialDesignColor "v1.x.x". Thus, we >> follow the changes of MaterialDesignColor while it's not a major >> release. >> Because of this situation, BaselineOfMaterialDesignLite is >> different on the two branches. Later, if I want to merge >> development into master in order to release a new version, master >> will get the BaselineOfMaterialDesignLite with semantic >> versionning dependencies instead of the fixed dependencies. >> Before the release I'll need to change the Baseline to get fix >> dependencies once again. >> I hope I was clearer. :) >> >> When you release a version, please do not move that version. >> You should then create new versions, with new numbers and new >> code. But never touch old versions with old numbers and old >> code. Like that I can download the same old code using the >> same old number to get the old version whenever I want :). >> >> You can try to do it with branches, tags, different >> repositories, or even with zipfiles in mails. I don't care. >> Just don't modify releases and I'm happy with it. >> >> >> >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr > >

March 5, 2018