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

Re: [Pharo-dev] Segmentation fault while installing Scale

by Stephane Ducasse

Hi andrey can you tell us on which OS and version and which VM do you use (there is a System report browser where you can find the information. Tx On Mon, Feb 6, 2017 at 8:20 PM, Andrey Tykhonov <atykhonov(a)gmail.com> wrote: > Hi all! > > While executing the following command: > > $ wget -O- https://raw.githubusercontent.com/guillep/Scale/master/ > setupScale.sh | sudo bash > stderr.log > > I got the Segmentation fault error. You can see it in the contents of > stderr.log which is attached to the email. Here you can see the > output of the mentioned command: > > ``` > --2017-02-03 19:35:16-- https://raw.githubusercontent.com/guillep/ > Scale/master/setupScale.sh > Resolving raw.githubusercontent.com... 151.101.128.133, 151.101.192.133, > 151.101.64.133, ... > Connecting to raw.githubusercontent.com|151.101.128.133|:443... connected. > HTTP request sent, awaiting response... 200 OK > Length: 1021 [text/plain] > Saving to: âSTDOUTâ > > - 100%[========================= > ====================================>] 1021 --.-KB/s in 0s > > 2017-02-03 19:35:16 (274 MB/s) - written to stdout [1021/1021] > > Cloning into '/tmp/scale'... > remote: Counting objects: 1457, done. > remote: Total 1457 (delta 0), reused 0 (delta 0), pack-reused 1457 > Receiving objects: 100% (1457/1457), 656.60 KiB | 714.00 KiB/s, done. > Resolving deltas: 100% (799/799), done. > Note: checking out 'f70fdb90cf66d443140b6fe84cad9848163bf32e'. > > You are in 'detached HEAD' state. You can look around, make experimental > changes and commit them, and you can discard any commits you make in this > state without impacting any branches by performing another checkout. > > If you want to create a new branch to retain commits you create, you may > do so (now or later) by using -b with the checkout command again. Example: > > git checkout -b <new-branch-name> > > --2017-02-03 19:35:18-- http://get.pharo.org/50+vm > Resolving get.pharo.org... 128.93.162.72 > Connecting to get.pharo.org|128.93.162.72|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 2901 (2.8K) [text/html] > Saving to: âSTDOUTâ > > - 100%[========================= > ====================================>] 2.83K --.-KB/s in 0.001s > > 2017-02-03 19:35:18 (3.56 MB/s) - written to stdout [2901/2901] > > Downloading the latest 50 Image: > http://files.pharo.org/get-files/50/pharo.zip > Downloading the latest pharoVM: > http://files.pharo.org/get-files/50/pharo-linux-stable.zip > Downloading PharoV50.sources: > http://files.pharo.org/get-files/50/sources.zip > Creating starter scripts pharo and pharo-ui > > Fetched -> BaselineOfScale-SantiagoBragagnolo.4 --- > filetree:///tmp/scale/src [:] --- filetree:///tmp/scale/src./pharo: line > 11: 19176 Aborted "$DIR"/"pharo-vm/pharo" --nodisplay "$@" > Syntax Error on line 26: 'Unmatched '' in string literal. ->' > ============================================================= > 01: | scapeParentDirectory pharoParentDirectory scaleX scaleuiX | > 02: > 03: system stdout << 'Uninstalling scale' << String cr. > 04: > 05: system saveImageAs: #/ asFileReference / #tmp / #'uninstall.image'. > 06: " The image must be stored elsewhere for deleting all the files " > 07: > 08: scaleX := '/usr/local/bin/scale' asFileReference. > 09: scaleX exists ifTrue: [ system call: ' rm ', scaleX fullName ]. > 10: system stdout << 'Uninstalling executable scale' << String cr ; flush. > 11: > 12: scaleuiX:='/usr/local/bin/scale-ui' asFileReference. > 13: scaleuiX exists ifTrue: [ system call: ' rm ', scaleuiX fullName ]. > 14: system stdout << 'Uninstalling executable scale-ui' << String cr ; > flush. > 15: > 16: scapeParentDirectory := '/usr/local/scale' asFileReference. > 17: pharoParentDirectory := '/usr/local/pharo' asFileReference. > 18: > 19: scapeParentDirectory exists ifTrue: [ system call: ' rm -rf ', > scapeParentDirectory fullName ]. > 20: system stdout << 'Removing scale folder' << String cr ; flush. > 21: > 22: pharoParentDirectory exists ifTrue: [ system call: ' rm -rf ', > pharoParentDirectory fullName ]. > 23: system stdout << 'Removing pharo folder' << String cr ; flush. > 24: > 25: > 26: system stdout << 'Done > _^_ > Syntax Error on line 39: 'Unmatched '' in string literal. ->' > ============================================================= > 01: | scaleParentDirectory scaleFile scaleUIFile pharoParentDirectory| > 02: > 03: " DEPLOY " > 04: system stdout << 'Deploying scale command';cr. > 05: > 06: scaleParentDirectory := '/usr/local/scale' asFileReference. > 07: > 08: scaleParentDirectory exists > 09: ifTrue: [ > 10: system stderr << 'There is already an installation. Please > uninstall before' > 11: ] ifFalse: [ > 12: scaleParentDirectory ensureCreateDirectory. > 13: scaleFile := scaleParentDirectory / 'scale'. > 14: scaleUIFile := scaleParentDirectory / 'scale-ui'. > 15: system workingDirectory / '..' / 'scale' copyTo: scaleFile. > 16: system workingDirectory / '..' / 'scale-ui' copyTo: scaleUIFile. > 17: system workingDirectory / '..' / #build / 'uninstall.st' copyTo: > scaleParentDirectory / 'uninstall.st'. > 18: system stdout << 'Deploying Pharo';cr. > 19: > 20: pharoParentDirectory := '/usr/local/pharo' asFileReference. > 21: pharoParentDirectory ensureCreateDirectory. > 22: #( 'pharo' 'pharo-vm' 'pharo-ui') > 23: do: [ :file | system workingDirectory / file copyAllTo: > pharoParentDirectory / file ]. > 24: > 25: #( 'Pharo.image' 'Pharo.changes') > 26: do: [ :file | system workingDirectory / file copyAllTo: > scaleParentDirectory / file ]. > 27: > 28: > 29: system stdout << 'Giving permissions to run';cr. > 30: > 31: system call: 'chmod +x ', (pharoParentDirectory / 'pharo') > fullName. > 32: system call: 'chmod +x ', (pharoParentDirectory / 'pharo-ui') > fullName. > 33: system call: 'chmod +x ', (pharoParentDirectory / > 'pharo-vm/pharo') fullName. > 34: system call: 'chmod +x ', (scaleParentDirectory / 'uninstall.st') > fullName. > 35: system call: 'chmod +x ', scaleFile fullName. > 36: system call: 'chmod +x ', scaleUIFile fullName. > 37: system ln: scaleFile to: '/usr/local/bin/scale' asFileReference. > 38: system ln: scaleUIFile to: '/usr/local/bin/scale-ui' > asFileReference. > 39: system stdout << 'Done > _^_ > ``` > > Could you please help me find a workaround in order to bypass this issue? > > Thank you in advance! > > -- > Andriy > > >

Feb. 7, 2017

Re: [Pharo-dev] Pharo 6 update catalog entries

by Dimitris Chloupis

Fair point, I will make the changes. Glad you find it useful, is there any new feature you want ? On Mon, 6 Feb 2017 at 18:05, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > kilon.alios wrote > > I see little reason to support individual pharo versions because I focus > > always on the latest version. > > I'm not suggesting that you maintain compatibility ongoingly with various > versions, but if you mark compatible versions as such in the catalog, users > won't get an unnecessary warning. Either way, thanks for the tool! I > happily > use it daily :) > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Pharo-6-update-catalog-entries-tp4932354p4933169.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Feb. 7, 2017

Printing numbers in different bases

by Benoit St-Jean

Is there a reason why we allow printing numbers in bases greater than 36?Â It makes no sense to me. For instance: 1406 printStringBase: 57.Â "O]"Â ----------------- BenoÃ®t St-Jean "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein)

Feb. 7, 2017

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

by Ben Coman

On Tue, Feb 7, 2017 at 5:59 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> > On Windows (10) (with latest 6 image and VM) `Time microsecondClockValue` returns microseconds, but (presumably the system) cannot give precision beyond 1 second - this will imho need a VM fix; >> >> I find that quite hard to believe and I did not know that. Are you really sure ? That would be terrible. A solution might be to use another clock primitive. >> >> > I can also generate about 1.2M UUIDs per second (limited by single core I guess), which means that about every 600-1200 consequential UUIDs will have the same clock value. >> >> I can't follow your reasoning here: if the clock precision would be 1 second, you would get 1.2M consecutive UUIDs with the same clock value, right ? > > Whoops, I meant the precision on a millisecond, not second... thus the ~1000k consecutive clock values. > The returned value is still in microseconds, but the last 3 digits are fixed (they are different on startup, but same during execution). This is a limitation of the Windows VM. I opened an issue to work on VM clock, but a few other side-tasks jumped above it while I was learning more about the VM code. https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/36 cheers -ben

Feb. 7, 2017

Re: [Pharo-dev] [QA] Debugger buttons explained

by Sven Van Caekenberghe

> On 6 Feb 2017, at 21:25, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > How about... > > Into > > Step into the highlighted message, i.e. dive the debugger into the method > which handles it > > Over > > Step over the highlighted message, i.e. execute it, but keep the debugger > focused on the current method > > Through > > Like stepping "Over", except step through block contents when executed > > Restart > > Rewind to the start of the current execution context, resetting all local > variables > > Continue > > Relinquish debugger control and proceed with normal execution Well simpler is of course better, but I think that the aspect of telling what the debugger will do, where it will stop is quite important. Unless it is clear for everybody that step implies to stop and having control return to the debugger. > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/QA-Debugger-buttons-explained-tp4933212p4933238.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 6, 2017

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

by Sven Van Caekenberghe

> On 6 Feb 2017, at 23:01, werner kassens <wkassens(a)libello.com> wrote: > > On 02/06/2017 09:00 PM, Sven Van Caekenberghe wrote: >> Regarding the poor seed at startup: >>> 1k outside runs of 'NeoUUIDGenerator new nextRandom16' (on a fresh image) gives me only 116 unique values, compared to the expected 990-1000 >>> In the above it's already second run of the generator, for (random initial) counter, there was only 69 unique values out of 1000. >> But that is not proper use of a random generator, you create a new instance every time. You basically test seeding, which is different from random number generator proper. >> > Hi, isnt it that, what the thread originally was about? as far as i understand it, it started with yuriy saying: > > The idea is that each time an image is started a new session is created and assigned a new UUID... Certainly for NeoUUIDGenerator, that will be the case, AFAIK. > werner

Feb. 6, 2017

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

by Sven Van Caekenberghe

> On 6 Feb 2017, at 22:59, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > >>> On Windows (10) (with latest 6 image and VM) `Time microsecondClockValue` returns microseconds, but (presumably the system) cannot give precision beyond 1 second - this will imho need a VM fix; >> >> I find that quite hard to believe and I did not know that. Are you really sure ? That would be terrible. A solution might be to use another clock primitive. >> >>> I can also generate about 1.2M UUIDs per second (limited by single core I guess), which means that about every 600-1200 consequential UUIDs will have the same clock value. >> >> I can't follow your reasoning here: if the clock precision would be 1 second, you would get 1.2M consecutive UUIDs with the same clock value, right ? > > Whoops, I meant the precision on a millisecond, not second... thus the ~1000k consecutive clock values. > The returned value is still in microseconds, but the last 3 digits are fixed (they are different on startup, but same during execution). > > I faintly remember having the same issue in a different language years ago, because they had different APIs or some bullshit like that. > > So when I generate e.g. 10 random UUIDs I get: > > > (1 to: 10) collect: [ :i | NeoUUIDGenerator next ]. "an Array( > an UUID('349b2ccc-4404-0d00-a8e7-5c9c0ef2da37') > an UUID('349b2ccc-4404-0d00-a8e8-2f3a0ef2da37') > an UUID('349b2ccc-4404-0d00-a8e9-9e0b0ef2da37') > an UUID('349b2ccc-4404-0d00-a8ea-15520ef2da37') > an UUID('349b2ccc-4404-0d00-a8eb-fa5c0ef2da37') > an UUID('349b2ccc-4404-0d00-a8ec-d25f0ef2da37') > an UUID('349b2ccc-4404-0d00-a8ed-6a590ef2da37') > an UUID('349b2ccc-4404-0d00-a8ee-3a8d0ef2da37') > an UUID('349b2ccc-4404-0d00-a8ef-0ad20ef2da37') > an UUID('349b2ccc-4404-0d00-a8f0-7bda0ef2da37'))" I don't see any problem here, they are all different. Of course the clock part is the same during the same millisecond. >> In the unit tests this is verified (that the time value goes forward on consecutive calls). >> > > testTwo*Generator only tests if they are close, not that one is higher than the other, > > if I add > > self assert: time2 equals: time1. > > the test will still pass (but that is already obvious from the list above). > > > >>> 9 & 10 bytes are counter, but 9th bit is rewritten with variant, so the counter is actually 0-255 and not 0-65536. >> >> Yes, but more correctly, the top 2 bits are set to 10, making the range 1 to 2^14 (16384) (instead of 2^16). > > Welp, I can't do bit math. > >> >>> And finally 11 & 12 are random bits (assuming the seeding isn't broken). >> >> The seeding is one aspect (the quality of the seed), the algorithm is another. >> Note that in the current Random class, the seed is initialised using the clock as well. > > The problem with Random is not the time-based initialization, but masking of the initial value (which is mentioned in the originally linked thread on randomness, which fixes itself upon further generations). > >> >>> So on Windows, the conditional probability that nth and n+256th UUIDs will be identical is imho 1/65536 (assuming they are in the same second, which is easy). >> >> I am pretty/quite sure this is not correct but it would take me much more time to come up with a more correct calculation. > > With the actual counter I would have to generate 16384 UUID/milisecond, which unlike 256/ms I cannot do, so it is safe again. :) (well... until Pharo goes multicore) > >> >> BTW, you also have to define the context of being the same: the same instance of one NeoUUIDGenerator generating the same UUID, or several different generator instances, in the same image, in different images, on different runs, the same or different machines/networks, ... >> >>> On Linux my understanding is that clash can only happen if NTP adjusts my clock during UUID generation (at which point it is same as Windows). >>> >>> Can UUID clash be achieved on Linux if you deploy copies of the same image and let them all generate UUIDs? (It should be again 1/65536). > > Yeah, across machines the last four bytes behave randomly too. > > Maybe I can get clash if I run two random generators in forks (to fix 14 bits of counter randomness :) ... but no time for that now. :) > > Peter >

Feb. 6, 2017

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

by Sven Van Caekenberghe

> On 6 Feb 2017, at 22:33, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2017-02-04 13:40 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 4 Feb 2017, at 13:01, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi Nicolai, > > > > The FileSystem API is a bit inconsistent, yes. > > > > This is how you can use it: > > > > (FileLocator temp / 'foo.txt') writeStreamDo: [ :out | > > out binary. > > (ZnCharacterWriteStream on: out encoding: #utf8) << 'Ã©lÃ¨ve' ]. > > > > (FileLocator temp / 'foo.txt') readStreamDo: [ :in | > > in binary. > > ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. > > > > (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in | > > (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. > > > > There is no #binaryWriteStreamDo: > > > > The API around File is more correct, IMHO. > > > > Does this help ? > > > > Yes, thanks for the fast response. > > > > What exactly is your question ? > > > > I am looking at the issues with FileList, there are some parts that don't work anymore (see FileList>>#contents, it calls some unimplemted methods), and it uses TextConverter and somoe parts of the older File api. > > It looks like most other (newer) parts are using ZnCharacterReadstream for encoding, but I couldn't find a way to use it together with FileReferences (most parts of the FileList already operate with the newer FileSystem API. > > OK. > > From my standpoint and understanding, I would always use binary streams with explicit Zn converters, this combination is much easier to understand and better implemented with more features. > > If you encounter any problem or have any questions, I will gladly try to help you. > > :-) > Is there a way to list all supported encodings, similar to TextConverter class >> #allEncodingNames ? > I only found > ZnSimplifiedByteEncoder class >> #knownEncodingIdentifiers > and > ZnByteEncoder class >> #knownEncodingIdentifiers > and nothing for all supported utf-8/16 ... encodings. Ah, yes, you are right, I should add a #knownEncodingIdentifiers at the level of ZnCharacterEncoder that returns the union of all of them. I will add that tomorrow. > nicolai > > > > Sven > > > > > On 4 Feb 2017, at 12:09, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > Hi > > > How can I specify the character encoding when opening a readStream on a FileRerefence. > > > > > > I found this, that works: > > > > > > | readStream fileContent | > > > readStream := (File named: aFileName) openForRead. > > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding. > > > fileContent upToEnd asString. > > > > > > But if I try to do the same with a readStream from a FileReference > > > > > > | readStream fileContent | > > > readStream := aFileName asFileReference readStream. > > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding. > > > fileContent upToEnd asString. > > > > > > I get an error SmallInteger DNU #asciiValue, > > > > > > this is because, in the first method, we create a binary filestream, and if we > > > use readStream from a FileReference, the stream is a MultibyteFileStream. > > > > > > How can I us ZnEncoder for a readstream from a FileReference? > > > > > > (and is it on purpose that both readStream method (openForRead/readStream) > > > return different kinds of binary streams?) > > > > > > > > > nicolai

Feb. 6, 2017

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

by werner kassens

On 02/06/2017 09:00 PM, Sven Van Caekenberghe wrote: > Regarding the poor seed at startup: >> 1k outside runs of 'NeoUUIDGenerator new nextRandom16' (on a fresh image) gives me only 116 unique values, compared to the expected 990-1000 >> In the above it's already second run of the generator, for (random initial) counter, there was only 69 unique values out of 1000. > But that is not proper use of a random generator, you create a new instance every time. You basically test seeding, which is different from random number generator proper. > Hi, isnt it that, what the thread originally was about? as far as i understand it, it started with yuriy saying: The idea is that each time an image is started a new session is created and assigned a new UUID... werner

Feb. 6, 2017

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

by Peter Uhnak

> > On Windows (10) (with latest 6 image and VM) `Time microsecondClockValue` returns microseconds, but (presumably the system) cannot give precision beyond 1 second - this will imho need a VM fix; > > I find that quite hard to believe and I did not know that. Are you really sure ? That would be terrible. A solution might be to use another clock primitive. > > > I can also generate about 1.2M UUIDs per second (limited by single core I guess), which means that about every 600-1200 consequential UUIDs will have the same clock value. > > I can't follow your reasoning here: if the clock precision would be 1 second, you would get 1.2M consecutive UUIDs with the same clock value, right ? Whoops, I meant the precision on a millisecond, not second... thus the ~1000k consecutive clock values. The returned value is still in microseconds, but the last 3 digits are fixed (they are different on startup, but same during execution). I faintly remember having the same issue in a different language years ago, because they had different APIs or some bullshit like that. So when I generate e.g. 10 random UUIDs I get: (1 to: 10) collect: [ :i | NeoUUIDGenerator next ]. "an Array( an UUID('349b2ccc-4404-0d00-a8e7-5c9c0ef2da37') an UUID('349b2ccc-4404-0d00-a8e8-2f3a0ef2da37') an UUID('349b2ccc-4404-0d00-a8e9-9e0b0ef2da37') an UUID('349b2ccc-4404-0d00-a8ea-15520ef2da37') an UUID('349b2ccc-4404-0d00-a8eb-fa5c0ef2da37') an UUID('349b2ccc-4404-0d00-a8ec-d25f0ef2da37') an UUID('349b2ccc-4404-0d00-a8ed-6a590ef2da37') an UUID('349b2ccc-4404-0d00-a8ee-3a8d0ef2da37') an UUID('349b2ccc-4404-0d00-a8ef-0ad20ef2da37') an UUID('349b2ccc-4404-0d00-a8f0-7bda0ef2da37'))" > > In the unit tests this is verified (that the time value goes forward on consecutive calls). > testTwo*Generator only tests if they are close, not that one is higher than the other, if I add self assert: time2 equals: time1. the test will still pass (but that is already obvious from the list above). > > 9 & 10 bytes are counter, but 9th bit is rewritten with variant, so the counter is actually 0-255 and not 0-65536. > > Yes, but more correctly, the top 2 bits are set to 10, making the range 1 to 2^14 (16384) (instead of 2^16). Welp, I can't do bit math. > > > And finally 11 & 12 are random bits (assuming the seeding isn't broken). > > The seeding is one aspect (the quality of the seed), the algorithm is another. > Note that in the current Random class, the seed is initialised using the clock as well. The problem with Random is not the time-based initialization, but masking of the initial value (which is mentioned in the originally linked thread on randomness, which fixes itself upon further generations). > > > So on Windows, the conditional probability that nth and n+256th UUIDs will be identical is imho 1/65536 (assuming they are in the same second, which is easy). > > I am pretty/quite sure this is not correct but it would take me much more time to come up with a more correct calculation. With the actual counter I would have to generate 16384 UUID/milisecond, which unlike 256/ms I cannot do, so it is safe again. :) (well... until Pharo goes multicore) > > BTW, you also have to define the context of being the same: the same instance of one NeoUUIDGenerator generating the same UUID, or several different generator instances, in the same image, in different images, on different runs, the same or different machines/networks, ... > > > On Linux my understanding is that clash can only happen if NTP adjusts my clock during UUID generation (at which point it is same as Windows). > > > > Can UUID clash be achieved on Linux if you deploy copies of the same image and let them all generate UUIDs? (It should be again 1/65536). Yeah, across machines the last four bytes behave randomly too. Maybe I can get clash if I run two random generators in forks (to fix 14 bits of counter randomness :) ... but no time for that now. :) Peter

Feb. 6, 2017