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

[ANN] Camp Smalltalk 2019 in Charlotte, NC

by Mariano Martinez Peck

Greetings Fellow Smalltalkers, We would like to invite you to Camp Smalltalk, March 29th â March 31st 2019 in Charlotte, North Carolina. Event details and registration info are available at the following link: Camp Smalltalk Charlotte 2019 <https://www.eventbrite.com/e/camp-smalltalk-charlotte-2019-tickets-52380940…> Hope to see you there! -- Mariano

Nov. 14, 2018

[Pharo 7.0-dev] Build #1401: 22668-Contextual-menu-does-not-show-up-when-pressing-Ctrlleft-click-on-Pharo-7

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

There is a new Pharo build available! The status of the build #1401 was: SUCCESS. The Pull Request #1988 was integrated: "22668-Contextual-menu-does-not-show-up-when-pressing-Ctrlleft-click-on-Pharo-7" Pull request url: https://github.com/pharo-project/pharo/pull/1988 Issue Url: https://pharo.fogbugz.com/f/cases/22668 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 14, 2018

[Pharo 7.0-dev] Build #1400: 22659-generated-artifacts-should-have-the-version-tag (postscriptum to the notes to the commentaries to the addendum)

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

There is a new Pharo build available! The status of the build #1400 was: FAILURE. The Pull Request #1994 was integrated: "22659-generated-artifacts-should-have-the-version-tag (postscriptum to the notes to the commentaries to the addendum)" Pull request url: https://github.com/pharo-project/pharo/pull/1994 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 14, 2018

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo v7.0.0-rc1 released!

by Alistair Grant

Hi Vitor, On Wed, 14 Nov 2018 at 14:37, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > > Got instant red crossed welcome window on windows 7 64bits with the Pharo 7 64 bits: "Error: Instances of SourceFileArray are not indexable". I will try on a windows 10 version later. Which VM are you using? (pharoconsole --version) I've seen this just once on Ubuntu 16.04 (64 bit), but wasn't able to reproduce it, and think it was a more recent VM than the current stable version. Thanks, Alistair

Nov. 14, 2018

[Pharo 7.0-dev] Build #1399: 22659-generated-artifacts-should-have-the-version-tag (notes to the commentary to the addendum)

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

There is a new Pharo build available! The status of the build #1399 was: FAILURE. The Pull Request #1993 was integrated: "22659-generated-artifacts-should-have-the-version-tag (notes to the commentary to the addendum)" Pull request url: https://github.com/pharo-project/pharo/pull/1993 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 14, 2018

[Pharo 7.0-dev] Build #1398: 22659-generated-artifacts-should-have-the-version-tag (commentary to the addendum)

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

There is a new Pharo build available! The status of the build #1398 was: FAILURE. The Pull Request #1992 was integrated: "22659-generated-artifacts-should-have-the-version-tag (commentary to the addendum)" Pull request url: https://github.com/pharo-project/pharo/pull/1992 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 14, 2018

[Pharo 7.0-dev] Build #1396: 22659-generated-artifacts-should-have-the-version-tag (addendum to the addendum)

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

There is a new Pharo build available! The status of the build #1396 was: FAILURE. The Pull Request #1991 was integrated: "22659-generated-artifacts-should-have-the-version-tag (addendum to the addendum)" Pull request url: https://github.com/pharo-project/pharo/pull/1991 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 14, 2018

[Pharo 7.0-dev] Build #1395: 22659-generated-artifacts-should-have-the-version-tag (addendum)

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

There is a new Pharo build available! The status of the build #1395 was: FAILURE. The Pull Request #1990 was integrated: "22659-generated-artifacts-should-have-the-version-tag (addendum)" Pull request url: https://github.com/pharo-project/pharo/pull/1990 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 14, 2018

[Pharo 7.0-dev] Build #1394: 22659-generated-artifacts-should-have-the-version-tag (definitive compilation)

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

There is a new Pharo build available! The status of the build #1394 was: FAILURE. The Pull Request #1989 was integrated: "22659-generated-artifacts-should-have-the-version-tag (definitive compilation)" Pull request url: https://github.com/pharo-project/pharo/pull/1989 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 14, 2018

Re: [Pharo-dev] Debugger "Through" acting like "Into"

by Guillermo Polito

Hi Martin, On Wed, Nov 14, 2018 at 4:15 AM Martin McClure <martin(a)hand2mouse.com> wrote: > In the latest Pharo 7 > (Pharo-7.0.0+rc1.build.1384.sha.c34d6a69d9d01a2816df1f9fdc7388580163df29 > (32 Bit)) it seems like clicking "Through" in the debugger often (but > not always) has the effect of "Into", which seems wrong and makes > stepping through code difficult. I don't know how new this behavior is. > > Is this a known behavior? If not, I'll characterize it further. > Not that I know. >From the top of my head, step through should work like a step over, unless the execution flows into the block whose home = thisContext. What is the behaviour you expect? Just as a side note, we have a Phd student trying to understand the semantics of our debugger operations and they are not always so evident. We are trying to write tests for all these to "formalise" (:)) the semantics and have a battery to detect regressions. Guille

Nov. 14, 2018

Debugger "Through" acting like "Into"

by Martin McClure

In the latest Pharo 7 (Pharo-7.0.0+rc1.build.1384.sha.c34d6a69d9d01a2816df1f9fdc7388580163df29 (32 Bit)) it seems like clicking "Through" in the debugger often (but not always) has the effect of "Into", which seems wrong and makes stepping through code difficult. I don't know how new this behavior is. Is this a known behavior? If not, I'll characterize it further. Regards, -Martin

Nov. 14, 2018

Re: [Pharo-dev] How do I create a binary stream

by Stephane Ducasse

Thanks you all for the discussion. We should improve the comment of File and probably the one of FileReference. Tx Sven for the improvement of the comment of ImageReadWriter. Good comments are so important! We underestimate their impact. S On Sun, Nov 11, 2018 at 2:10 PM Hilaire <hilaire(a)drgeo.eu> wrote: > > I am quite happy with the new FileReference API. > > Le 11/11/2018 Ã 13:51, Sven Van Caekenberghe a Ã©crit : > > API changes are always annoying, but splitting reading and writing as well as binary and character streams is a clear improvement overall. > > > -- > Dr. Geo > http://drgeo.eu > > >

Nov. 13, 2018

[Pharo 7.0-dev] Build #1393: 22659-generated-artifacts-should-have-the-version-tag (V5)

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

There is a new Pharo build available! The status of the build #1393 was: FAILURE. The Pull Request #1987 was integrated: "22659-generated-artifacts-should-have-the-version-tag (V5)" Pull request url: https://github.com/pharo-project/pharo/pull/1987 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1392: 22659-generated-artifacts-should-have-the-version-tag (V4)

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

There is a new Pharo build available! The status of the build #1392 was: FAILURE. The Pull Request #1986 was integrated: "22659-generated-artifacts-should-have-the-version-tag (V4)" Pull request url: https://github.com/pharo-project/pharo/pull/1986 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1391: 22659-generated-artifacts-should-have-the-version-tag (V3)

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

There is a new Pharo build available! The status of the build #1391 was: FAILURE. The Pull Request #1984 was integrated: "22659-generated-artifacts-should-have-the-version-tag (V3)" Pull request url: https://github.com/pharo-project/pharo/pull/1984 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1390: 22659-generated-artifacts-should-have-the-version-tag (V2)

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

There is a new Pharo build available! The status of the build #1390 was: FAILURE. The Pull Request #1983 was integrated: "22659-generated-artifacts-should-have-the-version-tag (V2)" Pull request url: https://github.com/pharo-project/pharo/pull/1983 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

Re: [Pharo-dev] Better management of encoding of environment variables

by Guillermo Polito

I have to add also > Other Implementation Details > ========================= > > - VM primitives returning paths Strings should be carefuly managed to > decode them, since they are actually C strings (so byte arrays) disguised > as ByteStrings. > - Similar changes had to be applied to correctly obtain the current > working directory in case it is a wide string. > > - The default encoding assumed so far in *nixes is utf8. A more robust implementation could obtain this from the locale, but this would be too much of a change as all the locale code should be revisited too.

Nov. 13, 2018

Re: [Pharo-dev] Better management of encoding of environment variables

by Guillermo Polito

Hi all, Thanks Ben for reading. For those wanting a follow up, I've proposed this pull request: https://github.com/pharo-project/pharo/pull/1980. I'm still working on avoiding dependencies against UFFI, fixing one other test. This is however almost finished, and given that I had to adapt the original *abstract proposal* to fit the real system, here is an updated version: API Proposal for OSEnvironment and friends ========================= OSEnvironment is the common denominator for all platforms. They should implement at least the following messages with the following semantics: - *at: aVariableName [ifAbsent:/ifAbsentPut:/ifPresent:ifAbsent:]* Gets the String value of an environment variable called `aVariableName`. It is the system reponsibility to manage the encoding of *both arguments and return values*. - *at: aVariableName put: aValue* Sets the environment variable called `aVariableName` to value `aValue`. It is the system reponsibility to manage the encoding of *both arguments and return values*. - *removeKey: aVariableName* Removes the environment variable called `aVariableName`. It is the system reponsibility to manage the encoding of *both arguments and return values*. API Extensions for *Nix Systems (OSX & Linux) ========================= Since *Nixes environment variables are binary data that could be encoded in any encoding, the following methods provide more flexibility to access such data in the encoding of the choice of the user, or even in binary form. - *at: aVariableName encoding: anEncoding [ifAbsent:/ifAbsentPut:/ifPresent:ifAbsent:/put:] / removeKey:** aVariableName encoding: anEncoding* Variants of the common API from OSEnvironment. The encoding used as argument will be used to encode/decode *both arguments and return values*. - *rawAt: anEncodedVariableName encoding: anEncoding [ifAbsent:/ifAbsentPut:/ifPresent:ifAbsent:/put:] / removeRawKey:* *anEncodedVariableName* Variants of the common API from OSEnvironment. These methods assume arguments and return values are encoded/decoded by the user, so no marshalling or decoded is done by it. Rationale ========================= - Encoding/Decoding should be applied not only to values but to variables names too. In most cases Ascii overlaps with utf* and Latin* encodings, but this cannot be simply assumed. - Windows requires calling the right *Wide version of the functions from C, plus the correct encoding routine. This could be implemented as an FFI call or by modifying the VM to do it properly instead of calling the Ascii version. - Unix FileSystems and environment variables could mix strings in different encodings, thus the flexibility added by the low level *Nix extensions. Other Implementation Details ========================= - VM primitives returning paths Strings should be carefuly managed to decode them, since they are actually C strings (so byte arrays) disguised as ByteStrings. - Similar changes had to be applied to correctly obtain the current working directory in case it is a wide string. On Mon, Nov 12, 2018 at 1:31 PM Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, 12 Nov 2018 at 18:02, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> Hi all, >> >> following the meeting we had here @Inria headquarters, I'll be >> backporting some of the improvements we did in the launcher this last month >> regarding the encoding of environment variables. >> >> I've opened for this issue https://pharo.fogbugz.com/f/cases/22658/ >> >> We have already studied possible alternatives with Pablo and Christophe >> and we have some conclusions and we propose some changes: >> >> API Proposal for OSEnvironment >> ========================= >> >> >> - >> *at: aVariableName * >> >> Gets the String value of an environment variable called `aVariableName` >> It is the system reponsibility to manage the encoding. >> Rationale: A common denominator for all platforms providing an already >> decoded string, because windows does not (compared to *nix systems) provide >> a encoded byte representation of the value. Windows has instead its own >> wide string representation. >> >> - *[optionally] rawAt: anEncodedVariableName* >> >> Gets the Byte value of an environment variable called >> `anEncodedVariableName`. >> It is the user responsibility to encode and decode argument and return >> values in the encoding of this preference. >> Rationale: Some systems may want to have the liberty to use different >> encodings, or even to put binary data in the variables. >> >> - *[optionally] at: aVariableName encoding: anEncoding* >> >> Gets the value of an environment variable called `aVariableName` using >> `anEncoding` to encode/decode arguments and return values. >> Rationale: *xes could potentially use different encodings for their >> environment variables or even use different encodings in different parts of >> their file system. >> >> Other Implementation details >> ========================= >> >> - VM primitives returning paths Strings should be carefuly managed to >> decode them, since they are actually C strings (so byte arrays) disguised >> as ByteStrings. >> - Windows requires calling the right *Wide version of the functions >> from C, plus the correct encoding routine. This could be implemented as an >> FFI call or by modifying the VM to do it properly instead of calling the >> Ascii version >> >> > I haven't been using environment variables a lot so I don't have a strong > technical opinion (although at a glance it makes reasonable sense). > But I wanted to say I really like the way you've presented your offline > discussion, conclusions and proposal. Thanks. > > cheers -ben > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Nov. 13, 2018

[Pharo 7.0-dev] Build #1389: 22659-generated-artifacts-should-have-the-version-tag (V2)

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

There is a new Pharo build available! The status of the build #1389 was: FAILURE. The Pull Request #1983 was integrated: "22659-generated-artifacts-should-have-the-version-tag (V2)" Pull request url: https://github.com/pharo-project/pharo/pull/1983 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1388: 22657-The-closing-of-a-window-using-a-keyboard-can-close-a-window-without-focus

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

There is a new Pharo build available! The status of the build #1388 was: FAILURE. The Pull Request #1971 was integrated: "22657-The-closing-of-a-window-using-a-keyboard-can-close-a-window-without-focus" Pull request url: https://github.com/pharo-project/pharo/pull/1971 Issue Url: https://pharo.fogbugz.com/f/cases/22657 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1387: 22665-NECContextTesttestReceiverTempVar-is-failing-in-64-bit-image

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

There is a new Pharo build available! The status of the build #1387 was: FAILURE. The Pull Request #1979 was integrated: "22665-NECContextTesttestReceiverTempVar-is-failing-in-64-bit-image" Pull request url: https://github.com/pharo-project/pharo/pull/1979 Issue Url: https://pharo.fogbugz.com/f/cases/22665 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1386: 22664-many-Opal-tests-are-failing-on-64-bit-image

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

There is a new Pharo build available! The status of the build #1386 was: FAILURE. The Pull Request #1982 was integrated: "22664-many-Opal-tests-are-failing-on-64-bit-image" Pull request url: https://github.com/pharo-project/pharo/pull/1982 Issue Url: https://pharo.fogbugz.com/f/cases/22664 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1385: 22662-IntervalTest-is-failing-on-64-bit-image

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

There is a new Pharo build available! The status of the build #1385 was: FAILURE. The Pull Request #1978 was integrated: "22662-IntervalTest-is-failing-on-64-bit-image" Pull request url: https://github.com/pharo-project/pharo/pull/1978 Issue Url: https://pharo.fogbugz.com/f/cases/22662 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1384: 22667-operation-support-for-Global-var-read-and-more-tests

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

There is a new Pharo build available! The status of the build #1384 was: FAILURE. The Pull Request #1981 was integrated: "22667-operation-support-for-Global-var-read-and-more-tests" Pull request url: https://github.com/pharo-project/pharo/pull/1981 Issue Url: https://pharo.fogbugz.com/f/cases/22667 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1383: 22666-add-refications-for-operation-for-message-and-method

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

There is a new Pharo build available! The status of the build #1383 was: SUCCESS. The Pull Request #1976 was integrated: "22666-add-refications-for-operation-for-message-and-method" Pull request url: https://github.com/pharo-project/pharo/pull/1976 Issue Url: https://pharo.fogbugz.com/f/cases/22666 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1382: 22558-FFICalloutresolveType-ignores-class-side-definition (v2)

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

There is a new Pharo build available! The status of the build #1382 was: FAILURE. The Pull Request #1899 was integrated: "22558-FFICalloutresolveType-ignores-class-side-definition (v2)" Pull request url: https://github.com/pharo-project/pharo/pull/1899 Issue Url: https://pharo.fogbugz.com/f/cases/22558 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

Pharo 7 speed compared to VW (was: The STON Specification, Cog speed, and namespaces/modules)

by Shaping

Does anyone know whether Pharo 7 is as fast as VW 7.10 or later? Do we have recent comparative benchmarks? The comparison should ignore potential GPU-based improvement in my algo; that will happen later. The test should involve some math, file streaming, and the parsing that entailsâan ordinary mix of macrobenchmarks. The comparison should be based on both Pharo 7 and VW each running a single Smalltalk Process (one time-slice of one OS thread in one OS process). I need Pharo 7 speed to be comparable or better to justify the port. Pharo is definitely looking and working better. Iâve spend more time with it last few weeks than during the previous decade. Thanks to everyone for the effort and improvements. Shaping From: Shaping [mailto:shaping@uurda.org] Sent: Wednesday, November 7, 2018 00:41 To: 'Pharo Development List' <pharo-dev(a)lists.pharo.org> Subject: RE: [Pharo-dev] [ANN] The STON Specification, Cog speed, and namespaces/modules Hi Eliot. Pharo (& Squeak & Cuis) Float subclass BoxedFloat64 maps exactly to VW's Double. In 64-bit SmallFloat64 maps exactly to SmallDouble. But I wonder whether there is any issue here. STON would use the print strings for (PSC) Float / (VW) Double, and so deseerialization on Pharo would automatically produce the right class. Going in the other direction might need some help. APF needs support in PSC before one can port, but are representable as suitably-sized word arrays. There is no support for __float128 anywhere in the VM (e.g. not even in the FFI) on PSC as yet. I see Pharoâs WordArray. Iâll work on an APF for Pharo, as time permits. Iâm using APFs in VW in the 300-bit range, and want to reduce the needed precision to 64 bits, to save space and time on large (5 million+) scalar time-series, both on the heap and during BOSSing (25 m save-time now). The problem is not so much an issue for the JulianDayNumber (JDN)-precision, which is adequate in this app at 14 to 15 digits (even though my JDN class subclasses APF, for now). Other calculations need the more extreme precision. I think I can make 128-bit floats work, and would really like to see a small, fast, boxed 128-bit float implementation in Pharo or VW. The APFs are big and slow. Where in the queue of planned improvements to Pharo does such a task lie? I suspect itâs not a very popular item. Broadening the issue somewhat, Iâm trying to find as many good reasons as possible to justify the work needed to port all my VW stuff to Pharo. Iâve seen the references to Cogâs speed and coming speed-up. Are there recent (say, in the last year) benchmarks comparing VW and Pharo? Any details here would be very much appreciated. Having no namespaces in Pharo is, I think, the biggest impediment. I prefer not to prefix class names, but there may be fewer name-collisions than I suppose--maybe none. Still, I need to know how VW and Pharo classes map in order to place overrides and extensions correctly. Besides the mentioned float-class mappings is there a reference on this? Object allSubclasses in Pharo 7 64-bit, produces 14946 classes. Pharo is a little bigger than it used to be. I suppose I donât need to check all unloaded packages because all classes in each of those will have the same unique prefix. Is that correct? Or, I could just load every package I can find, before I check names. But that little experiment has never gone well in the past. Is the Pharo-with-namespaces issue dead or merely suspended, awaiting a more fitting idea than what VW currently offers? Shaping On Tue, Nov 6, 2018 at 12:56 AM Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: STON is able to serialise Pharoâs Floats, what do you mean by double ? Floating-point numbers in IEEE 64-bit format, 14 or 15 significant digits, with a range between =10^307 and 10^307. Additionally, I recently asked Sven if t would be possible to store ScaledDecimals (I think it implements what you call ArbitraryPrecisionFloats) without loss of precision. Iâm referring to VWâs Double (and SmallDouble in 64-bit engines/images). APFs are binary representations that can be arbitrarily large, using Integers (LargePositiveIntegers for example) to model the bits of the mantissa. Before, because STON extends JSON, it was storing all kind of numbers either as float or integer. Now, thanks to Sven, STON stores ScaledDecimals correctly (without loss of precision through serialisation as float, what was done before). But I do not know if this change is integrated in recent images yet. â¦.. Number subclass: #Float instanceVariableNames: '' classVariableNames: 'E Epsilon Halfpi Infinity Ln10 Ln2 MaxVal MaxValLn MinValLogBase2 NaN NegativeInfinity NegativeZero Pi RadiansPerDegree Sqrt2 ThreePi Twopi' poolDictionaries: '' category: 'Kernel-Numbers' My instances represent IEEE-754 floating-point double-precision numbers. They have about 16 digits of accuracy and their range is between plus and minus 10^307. Some valid examples are: 8.0 13.3 0.3 2.5e6 1.27e-30 1.27e-31 -12.987654e12 â¦. I see that Pharoâs Float is VWâs Double. So then I just need to be able to serialize APF. â¦. FIFloatType subclass: #FFIFloat128 instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'UnifiedFFI-Types' I'm a 128bits (cuadruple precision) float. It is usually not used, but some compiler modes support it (__float128 in gcc) THIS IS NOT YET SUPPORTED â¦. The class above is also from the Pharo 7 image. This is the largest of the c-type FFIFloats. Any Float classes of this size and larger for the Smalltalk heap on 64-bit Pharo? Cheers, Shaping Le 6 nov. 2018 Ã 06:58, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > a Ã©crit : (Having domain problems recently. Please excuse this posting if you have seen it twice. I've not seen it appear yet on the list.) Can STON be extended to handle Doubles and ArbitraryPrecisionFloats? Shaping -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of David T. Lewis Sent: Wednesday, October 31, 2018 14:58 To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] [ANN] The STON Specification This is very clear and well written. Dave Hi, Since there can never be enough documentation I finally took some time to write a more formal description of STON as a data format. https://github.com/svenvc/ston/blob/master/ston-spec.md The idea is to let this stabilise a bit and to then update the two other documents describing STON, where necessary: https://github.com/svenvc/ston/blob/master/ston-paper.md https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuc cessfulBuild/artifact/book-result/STON/STON.html Also, the latest changes in STON have to make their way to the Pharo image as well. https://github.com/svenvc/ston All feedback is welcome. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org -- _,,,^..^,,,_ best, Eliot

Nov. 13, 2018

Re: [Pharo-dev] Anyone else seen crashes like these ?

by Eliot Miranda

Hi Ben, On Mon, Nov 12, 2018 at 8:51 AM Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, 12 Nov 2018 at 21:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi, >> >> I run Pharo 7 64-bit on a macOS laptop, where the images are kept running >> across sleep/wake cycles. >> > > Just to confirm, you mean your laptop sleep/wake cycle. > On my Window 10 laptop I do the same quite often with no problems. > > >> For many weeks, it often happens that an image crashes before/after such >> a sleep/wakeup (not all the time, just regularly). >> >> Here is a crash dump from today (fresh image/vm from WE, nothing special >> loaded). >> >> Related to scheduling ? Event handling ? > > > In trying to understand the last few moments, is the recent primitives > list strongly ordered in time?... > Most recent primitives > signal > nowTick > primSignal:atUTCMicroseconds: > wait > millisecondClockValue > @ > actualScreenSize > Yes, it's a log of the most recent 256 named primitives. Note that they're irrelevant in this case. The crash is always rooted in vmIOProcessEvents. i.e. the VM is responding to some input event, and it calls pumpRunLoop to do (Objective-C) [NSRunLoop mainRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantPast], which in Smalltalk would be written NSRunLoop mainRunLoop runMode: NSDefaultRunLoopMode beforeDate: NSDate distantPast. And somewhere within this a display update occurs which crashes, presumably because we're using stale data that should have been invalidated oil sleep and refreshed on wake. > > > Starting at #actualScreenSize, instrumenting the code by adding... > Transcript crShow: thisContext sender printString. > indicates the following call chain... > DisplayScreen-class>>actualScreenSize > MorphicUIManager>>checkForNewDisplaySize > DisplayScreen class>>checkForNewScreenSize > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldMorph>>doOneCycle > WorldMorph class>>doOneCycle > MorphicUIManager>>spawnNewProcess > > In detail from a static analysis of the code... > > WorldState>>doOneCycleNowFor: > > DisplayScreen class>>checkForNewScreenSize > > MorphicUIManager>>checkForNewDisplaySize > > DisplayScreen-class>>actualScreenSize > PRIMITIVE > < MorphicUIManager>>checkForNewDisplaySize > < DisplayScreen class>>checkForNewScreenSize > < WorldState>>doOneCycleNowFor > < WorldState>>doOneCycleFor: > < WorldMorph>>doOneCycle > < WorldMorph class>>doOneCycle > < MorphicUIManager>>spawnNewProcess > > WorldMorph class>>doOneCycle > > WorldMorph>>doOneCycle > > WorldState>>doOneCycleNowFor: > > WorldState>>interCyclePause: > > Time>>millisecondClockValue PRIMITIVE > < WorldState>>interCyclePause: > > Delay>>schedule > > DelaySemaphoreScheduler>>schedule: > > Semaphore>>wait > PRIMITIVE "readyToSchedule variable" > > Semaphore>>signal > PRIMITIVE "timingSemaphore variable" NOT RECORDED > > maybe context change causes this to be recorded later in "Most > recent primitives" > > > DelayMicrosecondTicker>>waitForUserSignalled:orExpired: waking up from > Semaphore>>wait > the primSignal:atUTCMicroseconds: > PRIMITIVE immediately before the #wait seems to have been logged now in > "Most recent primitives" > > > DelaySemaphoreScheduler>>scheduleAtTimingPriority > > Semaphore>>signal > PRIMITIVE "readyToSchedule variable" seems to have not been recorded in > "Most recent primitives" > > > DelayBasicScheduler>>scheduleAtTimingPriority > < > DelaySemaphoreScheduler>>scheduleAtTimingPriority > < > DelayBasicScheduler>>runBackendLoopAtTimingPriority > > DelayMicrosecondTicker>>nowTick > PRIMITIVE > > Delay>>timingPrioritySignalExpired > > Semaphore>>signal > PRIMITIVE "delaySemaphore variable" CRASH > > Smalltalk stack dump: > 0x7ffee21d7138 M Delay>timingPrioritySignalExpired 0x113e3b138: a(n) > Delay > 0x7ffee21d7170 M [] in > DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority > 0x11453b8c0: a(n) DelaySemaphoreScheduler > 0x1169f51c8 s BlockClosure>ensure: > 0x1169f5828 s > DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority > 0x1169f5c38 s [] in > DelaySemaphoreScheduler(DelayBasicScheduler)>startTimerEventLoopPriority: > 0x1169fae10 s [] in BlockClosure>newProcess > > The only reason I can think that last semaphore call would be a problem is > if variable delaySemaphore was not a Semaphore, > but the C stack backtrace doesn't look like it crashes in the Semaphore > handling. > Its perhaps co-incidental with delay scheduling code is invoked fairly > often, that its the current process when this crash occurs. > > > To hep isolate the failure point, I would considering copying #nowTIck to > a multiple series like... > #nowTick1 > #nowTick2 > #nowTick3 > etc so that all of the sender sites can be made distinct. > And maybe the same for #signal senders within the delay scheduling code. > > One side-curiousity is I can't see where the primitive #@ is being called > from. > Does it indicate some loop as its trying to determine > > To me the "vmIOProcessEvents" in the C backtrace with a fairly deep stack > into the AppKit framework > indicates its related to event handling. > > cheers -ben > -- _,,,^..^,,,_ best, Eliot

Nov. 13, 2018

Re: [Pharo-dev] Anyone else seen crashes like these ?

by Eliot Miranda

Hi Sven, On Mon, Nov 12, 2018 at 5:37 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I run Pharo 7 64-bit on a macOS laptop, where the images are kept running > across sleep/wake cycles. > > For many weeks, it often happens that an image crashes before/after such a > sleep/wakeup (not all the time, just regularly). > > Here is a crash dump from today (fresh image/vm from WE, nothing special > loaded). > > Related to scheduling ? Event handling ? > The stack trace points to OpenGL rendering: 2 Pharo sigsegv + 155 3 libsystem_platform.dylib _sigtramp + 29 4 ??? 0x0 + 0 5 AppleIntelKBLGraphicsGLDriver glrUpdateTexture + 8979 6 libGPUSupportMercury.dylib gpusLoadCurrentTextures + 591 7 AppleIntelKBLGraphicsGLDriver updateDispatch + 663 8 GLEngine gleDoDrawDispatchCore + 629 9 GLEngine glDrawArraysInstanced_STD_Exec + 264 10 GLEngine glDrawArrays_UnpackThread + 40 11 GLEngine gleCmdProcessor + 77 12 libdispatch.dylib _dispatch_client_callout + 8 13 libdispatch.dylib _dispatch_lane_barrier_sync_invoke_and_complete + 60 14 GLEngine glFlush_ExecThread + 15 15 Pharo -[sqSqueakOSXOpenGLView drawRect:flush:] + 301 16 Pharo -[sqSqueakOSXOpenGLView drawRect:] + 43 17 AppKit _NSViewDrawRect + 66 18 AppKit -[NSView _drawRect:clip:] + 1745 19 AppKit -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1400 20 AppKit -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2622 21 AppKit -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 938 22 AppKit -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 65 23 AppKit -[NSView _oldDisplayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 1887 24 AppKit -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 253 25 AppKit -[NSView displayIfNeeded] + 1300 26 AppKit -[NSWindow displayIfNeeded] + 283 27 AppKit __NSWindowGetDisplayCycleObserverForDisplay_block_invoke + 722 28 AppKit NSDisplayCycleObserverInvoke + 170 29 AppKit NSDisplayCycleFlush + 1073 30 QuartzCore _ZN2CA11Transaction19run_commit_handlersE18CATransactionPhase + 49 31 QuartzCore _ZN2CA11Transaction6commitEv + 186 32 AppKit __65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke + 274 33 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 34 CoreFoundation __CFRunLoopDoObservers + 452 35 CoreFoundation __CFRunLoopRun + 1166 36 CoreFoundation CFRunLoopRunSpecific + 463 37 Foundation -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 280 38 Pharo -[sqSqueakMainApplication(events) pumpRunLoop] + 103 39 Pharo -[sqSqueakOSXApplication(events) pumpRunLoop] + 43 40 Pharo vmIOProcessEvents + 255 and this is core VM code, so likely an pensmalltalk-vm macOS platform bug, hence best discussed on vm-dev. Can you describe exactly the steps you take to reproduce the crash? _,,,^..^,,,_ best, Eliot

Nov. 13, 2018

Re: [Pharo-dev] Anyone else seen crashes like these ?

by Ben Coman

On Tue, 13 Nov 2018 at 02:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes I mean laptop sleep/wake. > Thanks for looking into this. > But I think the first step is to see if this is repeatable for someone > else. > It is probably some graphics primitive rather than scheduling (I am > guessing here). > Seems so. Different Smalltalk stack. Very similar C backtrace. I've compared the two here... https://docs.google.com/spreadsheets/d/1pa8Ehwp9b0cW7NaSlElqvPQ5lzSbieike_h… cheers -ben

Nov. 12, 2018

Excel export with Tabular

by Hans-Martin Mosner

I put it on ss3 because I'm not yet familiar with the way Pharo uses github. Will look into it later. I'm unsure how git repositories are used in the Pharo context. Do you use them just like you use git normally (i.e. I use my git repository, you use yours and send me pull requests etc...). Are there any catalog systems that allow one to register and find projects? This whole issue has always been a bit confusing in the Squeak/Pharo world due to the number of different options. Cheers, Hans-Martin Am 11. November 2018 10:50:40 nachm. schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi Hans-Martin, > > This is great. I use Tabular too and was missing active development/maintenance. It would be very good to see this > project move forward. It is quite important/useful in enterprise contexts. > > Thx, > > Sven > > PS: where did you commit the changes ? any chance of moving it to GitHub (too) ? > >> On 11 Nov 2018, at 22:16, Hans-Martin <pharo-dev(a)fam-mosner.de> wrote: >> >> Hello folks, >> I have a need for creating excel files with more than 3 worksheets, so I >> took the Tabular code and beefed up the exporter a little. It does handle >> more worksheets now, uses XMLWriter to create all the ZIP members, and is >> properly named now (the class was called TabularXSLXExport, note swapped S >> and L). >> Some tests have been added, there are a number of items that I plan to to as >> time allows: >> - Add (possibly limited) support for styles and formulas which I >> specifically need for the project I'm working on so I could write files with >> the desired layout and functionality. >> - Add support for reading more aspects of XLSX files, preferrably as much as >> needed to be able to read and write most files without loss. >> - Add rendering, maybe at the basic morphic level, maybe using something >> else as I'm not really up-to-date regarding the developments in Pharo. >> - Add formula evaluation. >> - Add editing capabilites to have a fully functional spreadsheet (really far >> off). >> >> Cheers, >> Hans-Martin >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>

Nov. 12, 2018

Re: [Pharo-dev] Anyone else seen crashes like these ?

by Sven Van Caekenberghe

Yes I mean laptop sleep/wake. Thanks for looking into this. But I think the first step is to see if this is repeatable for someone else. It is probably some graphics primitive rather than scheduling (I am guessing here). I just got it again: VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git C stack backtrace & registers: rax 0x00000001136aa000 rbx 0x0000000129e014e0 rcx 0x0000000000000020 rdx 0x0000000000000ca0 rdi 0x00000001136abb20 rsi 0x00000001136abb20 rbp 0x00007ffeea3f98b0 rsp 0x00007ffeea3f98b0 r8 0x0000000000000006 r9 0x0000000000000006 r10 0x00000000000010bc r11 0xffffffffe98a8b20 r12 0x000000000000047f r13 0x0000000000002800 r14 0x00000001136aa000 r15 0x0000000000000000 rip 0x00007fff6e752e4d 0 libsystem_platform.dylib 0x00007fff6e752e4d _platform_memmove$VARIANT$Haswell + 365 1 Pharo 0x00000001058574f0 reportStackState + 952 2 Pharo 0x0000000105857837 sigsegv + 176 3 libsystem_platform.dylib 0x00007fff6e755b3d _sigtramp + 29 4 ??? 0x0000000000000000 0x0 + 0 5 AppleIntelKBLGraphicsGLDriver 0x00007fff39b6164f glrUpdateTexture + 8979 6 libGPUSupportMercury.dylib 0x00007fff5ce6f79d gpusLoadCurrentTextures + 591 7 AppleIntelKBLGraphicsGLDriver 0x00007fff39b50711 updateDispatch + 663 8 GLEngine 0x00007fff4b5d5078 gleDoDrawDispatchCore + 629 9 GLEngine 0x00007fff4b579369 glDrawArraysInstanced_STD_Exec + 264 10 GLEngine 0x00007fff4b57925a glDrawArrays_UnpackThread + 40 11 GLEngine 0x00007fff4b5d0ce1 gleCmdProcessor + 77 12 libdispatch.dylib 0x00007fff6e51ddcf _dispatch_client_callout + 8 13 libdispatch.dylib 0x00007fff6e529a2c _dispatch_lane_barrier_sync_invoke_and_complete + 60 14 GLEngine 0x00007fff4b527b85 glFlush_ExecThread + 15 15 Pharo 0x0000000105851b09 -[sqSqueakOSXOpenGLView drawRect:flush:] + 301 16 Pharo 0x00000001058519d6 -[sqSqueakOSXOpenGLView drawRect:] + 43 17 AppKit 0x00007fff3ea0a755 _NSViewDrawRect + 66 18 AppKit 0x00007fff3e9f5552 -[NSView _drawRect:clip:] + 1745 19 AppKit 0x00007fff3e9f43f3 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1400 20 AppKit 0x00007fff3e9f48b9 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2622 21 AppKit 0x00007fff3e9f24f8 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 938 22 AppKit 0x00007fff3e9f2128 -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 65 23 AppKit 0x00007fff3e9efa5a -[NSView _oldDisplayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 1887 24 AppKit 0x00007fff3e9ef099 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 253 25 AppKit 0x00007fff3e9ebc86 -[NSView displayIfNeeded] + 1300 26 AppKit 0x00007fff3e9e8a20 -[NSWindow displayIfNeeded] + 283 27 AppKit 0x00007fff3e9e885f __NSWindowGetDisplayCycleObserverForDisplay_block_invoke + 722 28 AppKit 0x00007fff3e9e3966 NSDisplayCycleObserverInvoke + 170 29 AppKit 0x00007fff3e9e34db NSDisplayCycleFlush + 1073 30 QuartzCore 0x00007fff4c3321b3 _ZN2CA11Transaction19run_commit_handlersE18CATransactionPhase + 49 31 QuartzCore 0x00007fff4c331b7a _ZN2CA11Transaction6commitEv + 186 32 AppKit 0x00007fff3e9e2e41 __65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke + 274 33 CoreFoundation 0x00007fff413e86ad __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 34 CoreFoundation 0x00007fff413e85e2 __CFRunLoopDoObservers + 452 35 CoreFoundation 0x00007fff4138a109 __CFRunLoopRun + 1166 36 CoreFoundation 0x00007fff41389a28 CFRunLoopRunSpecific + 463 37 Foundation 0x00007fff436f03ba -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 280 38 Pharo 0x0000000105858297 -[sqSqueakMainApplication(events) pumpRunLoop] + 103 39 Pharo 0x000000010584c2bd -[sqSqueakOSXApplication(events) pumpRunLoop] + 43 40 Pharo 0x0000000105855628 vmIOProcessEvents + 255 41 Pharo 0x00000001058556a7 ioProcessEvents + 56 42 Pharo 0x00000001057e15ba checkForEventsMayContextSwitch + 760 43 Pharo 0x00000001057e54ca ceStackOverflow + 110 44 ??? 0x000000010c73c5b3 0x0 + 4503881139 45 Pharo 0x00000001057d0d41 interpret + 631 46 Pharo 0x0000000105858c65 -[sqSqueakMainApplication runSqueak] + 393 47 Foundation 0x00007fff437fbc73 __NSFirePerformWithOrder + 381 48 CoreFoundation 0x00007fff413e86ad __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 49 CoreFoundation 0x00007fff413e85e2 __CFRunLoopDoObservers + 452 50 CoreFoundation 0x00007fff4138a109 __CFRunLoopRun + 1166 51 CoreFoundation 0x00007fff41389a28 CFRunLoopRunSpecific + 463 52 HIToolbox 0x00007fff40622b35 RunCurrentEventLoopInMode + 293 53 HIToolbox 0x00007fff40622774 ReceiveNextEventCommon + 371 54 HIToolbox 0x00007fff406225e8 _BlockUntilNextEventMatchingListInModeWithFilter + 64 55 AppKit 0x00007fff3e8deeb7 _DPSNextEvent + 997 56 AppKit 0x00007fff3e8ddc56 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1362 57 AppKit 0x00007fff3e8d7cb9 -[NSApplication run] + 699 58 AppKit 0x00007fff3e8c73f7 NSApplicationMain + 780 59 libdyld.dylib 0x00007fff6e56c08d start + 1 Smalltalk stack dump: 0x7ffeea425ef8 M Array(SequenceableCollection)>do: 0x10cde3bb8: a(n) Array 0x7ffeea425f48 M WorldState>displayWorld:submorphs: 0x10d8049d8: a(n) WorldState 0x7ffeea425f88 M WorldMorph>displayWorld 0x10d7f9bb8: a(n) WorldMorph 0x7ffeea425fc0 M [] in WorldState>displayWorldSafely: 0x10d8049d8: a(n) WorldState 0x7ffeea425ff0 M BlockClosure>on:do: 0x10cd95ef8: a(n) BlockClosure 0x7ffeea426030 M BlockClosure>ifError: 0x10cd95ef8: a(n) BlockClosure 0x7ffeea426068 M WorldState>displayWorldSafely: 0x10d8049d8: a(n) WorldState 0x7ffeea4260a0 M WorldState>doOneCycleNowFor: 0x10d8049d8: a(n) WorldState 0x7ffeea4260d8 M WorldState>doOneCycleFor: 0x10d8049d8: a(n) WorldState 0x7ffeea426110 M WorldMorph>doOneCycle 0x10d7f9bb8: a(n) WorldMorph 0x7ffeea426140 M WorldMorph class>doOneCycle 0x10d7f30c8: a(n) WorldMorph class 0x7ffeea426170 M [] in MorphicUIManager>spawnNewProcess 0x10df481b0: a(n) MorphicUIManager 0x10df48298 s [] in BlockClosure>newProcess Most recent primitives basicAt: basicAt: basicAt: **StackOverflow** basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: @ @ @ @ @ @ bitAnd: basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: @ @ copyBits @ @ @ @ @ truncated truncated @ truncated truncated @ @ @ bitAnd: @ @ = copyBits fractionPart truncated fractionPart truncated drawLoopX:Y: copyBits @ @ @ @ @ **StackOverflow** basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: @ @ @ @ @ @ @ @ @ @ @ @ @ @ truncated truncated truncated truncated @ @ @ @ @ @ @ @ @ @ @ @ @ @ **StackOverflow** **StackOverflow** **StackOverflow** @ @ @ @ @ @ @ @ @ **StackOverflow** basicAt: basicAt: basicAt: **StackOverflow** basicAt: basicAt: basicAt: @ @ @ @ @ @ @ @ @ @ **StackOverflow** truncated truncated truncated truncated @ @ **StackOverflow** @ @ truncated truncated truncated truncated @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ stringHash:initialHash: @ @ @ @ @ @ bitAnd: truncated fractionPart truncated truncated **StackOverflow** **StackOverflow** **StackOverflow** copyBitsColor:alpha:gammaTable:ungammaTable: truncated fractionPart truncated truncated **StackOverflow** copyBitsColor:alpha:gammaTable:ungammaTable: truncated fractionPart truncated truncated **StackOverflow** copyBitsColor:alpha:gammaTable:ungammaTable: truncated fractionPart truncated truncated **StackOverflow** copyBitsColor:alpha:gammaTable:ungammaTable: truncated fractionPart truncated truncated copyBitsColor:alpha:gammaTable:ungammaTable: truncated fractionPart truncated truncated copyBitsColor:alpha:gammaTable:ungammaTable: truncated fractionPart truncated truncated copyBitsColor:alpha:gammaTable:ungammaTable: truncated fractionPart truncated truncated copyBitsColor:alpha:gammaTable:ungammaTable: truncated fractionPart truncated truncated copyBitsColor:alpha:gammaTable:ungammaTable: truncated fractionPart truncated truncated copyBitsColor:alpha:gammaTable:ungammaTable: truncated fractionPart truncated truncated copyBitsColor:alpha:gammaTable:ungammaTable: @ @ @ @ @ @ basicAt: basicAt: basicAt: basicAt: basicAt: basicAt: @ @ @ @ @ @ @ copyBits @ @ @ @ primShowRectLeft:right:top:bottom: stack page bytes 4096 available headroom 1480 minimum unused headroom 624 (Segmentation fault) ./pharo-ui: line 11: 68918 Abort trap: 6 "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" "$@" > On 12 Nov 2018, at 17:50, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Mon, 12 Nov 2018 at 21:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I run Pharo 7 64-bit on a macOS laptop, where the images are kept running across sleep/wake cycles. > > Just to confirm, you mean your laptop sleep/wake cycle. > On my Window 10 laptop I do the same quite often with no problems. > > For many weeks, it often happens that an image crashes before/after such a sleep/wakeup (not all the time, just regularly). > > Here is a crash dump from today (fresh image/vm from WE, nothing special loaded). > > Related to scheduling ? Event handling ? > > In trying to understand the last few moments, is the recent primitives list strongly ordered in time?... > Most recent primitives > signal > nowTick > primSignal:atUTCMicroseconds: > wait > millisecondClockValue > @ > actualScreenSize > > > Starting at #actualScreenSize, instrumenting the code by adding... > Transcript crShow: thisContext sender printString. > indicates the following call chain... > DisplayScreen-class>>actualScreenSize > MorphicUIManager>>checkForNewDisplaySize > DisplayScreen class>>checkForNewScreenSize > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldMorph>>doOneCycle > WorldMorph class>>doOneCycle > MorphicUIManager>>spawnNewProcess > > In detail from a static analysis of the code... > > WorldState>>doOneCycleNowFor: > > DisplayScreen class>>checkForNewScreenSize > > MorphicUIManager>>checkForNewDisplaySize > > DisplayScreen-class>>actualScreenSize PRIMITIVE > < MorphicUIManager>>checkForNewDisplaySize > < DisplayScreen class>>checkForNewScreenSize > < WorldState>>doOneCycleNowFor > < WorldState>>doOneCycleFor: > < WorldMorph>>doOneCycle > < WorldMorph class>>doOneCycle > < MorphicUIManager>>spawnNewProcess > > WorldMorph class>>doOneCycle > > WorldMorph>>doOneCycle > > WorldState>>doOneCycleNowFor: > > WorldState>>interCyclePause: > > Time>>millisecondClockValue PRIMITIVE > < WorldState>>interCyclePause: > > Delay>>schedule > > DelaySemaphoreScheduler>>schedule: > > Semaphore>>wait PRIMITIVE "readyToSchedule variable" > > Semaphore>>signal PRIMITIVE "timingSemaphore variable" NOT RECORDED > maybe context change causes this to be recorded later in "Most recent primitives" > > DelayMicrosecondTicker>>waitForUserSignalled:orExpired: waking up from Semaphore>>wait > the primSignal:atUTCMicroseconds: PRIMITIVE immediately before the #wait seems to have been logged now in "Most recent primitives" > > DelaySemaphoreScheduler>>scheduleAtTimingPriority > > Semaphore>>signal PRIMITIVE "readyToSchedule variable" seems to have not been recorded in "Most recent primitives" > > DelayBasicScheduler>>scheduleAtTimingPriority > < DelaySemaphoreScheduler>>scheduleAtTimingPriority > < DelayBasicScheduler>>runBackendLoopAtTimingPriority > > DelayMicrosecondTicker>>nowTick PRIMITIVE > > Delay>>timingPrioritySignalExpired > > Semaphore>>signal PRIMITIVE "delaySemaphore variable" CRASH > > Smalltalk stack dump: > 0x7ffee21d7138 M Delay>timingPrioritySignalExpired 0x113e3b138: a(n) Delay > 0x7ffee21d7170 M [] in DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority 0x11453b8c0: a(n) DelaySemaphoreScheduler > 0x1169f51c8 s BlockClosure>ensure: > 0x1169f5828 s DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority > 0x1169f5c38 s [] in DelaySemaphoreScheduler(DelayBasicScheduler)>startTimerEventLoopPriority: > 0x1169fae10 s [] in BlockClosure>newProcess > > The only reason I can think that last semaphore call would be a problem is if variable delaySemaphore was not a Semaphore, > but the C stack backtrace doesn't look like it crashes in the Semaphore handling. > Its perhaps co-incidental with delay scheduling code is invoked fairly often, that its the current process when this crash occurs. > > > To hep isolate the failure point, I would considering copying #nowTIck to a multiple series like... > #nowTick1 > #nowTick2 > #nowTick3 > etc so that all of the sender sites can be made distinct. > And maybe the same for #signal senders within the delay scheduling code. > > One side-curiousity is I can't see where the primitive #@ is being called from. > Does it indicate some loop as its trying to determine > > To me the "vmIOProcessEvents" in the C backtrace with a fairly deep stack into the AppKit framework > indicates its related to event handling. > > cheers -ben

Nov. 12, 2018

Re: [Pharo-dev] Pharo 7 RC - Changing to larger font breaks scrolling in code browsers

by Alistair Grant

Hi Sven, On Mon, 12 Nov 2018 at 17:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > Here is an annoying usability bug that I am experiencing and that sometimes drives me nuts. It has been there a while. > > Take a stock Pharo 7 RC image and don't change any setting. Browse the method #testAsDateAndTime as implemented by DateAndTimeTest. This is a (too) long (test) method. Any long method will do. > > You can scroll it fine in both the implementors and well as in the full browser. > > Now switch to 'Medium' sized 'predefined style' Standard Fonts using the Settings Browser. > > It is now close to impossible to scroll in the implementors or the full browser: not using the scroll bar arrows, not dragging the scroll bar, not clicking above/below the scroll bar, not using the scroll gesture (track pad, mouse pad, wheel), not using cursor keys inside the editor. Scrolling seems to happen automatically and goes on until the top or bottom. > > Can anyone replicate this ? On Ubuntu 16.04 with recent images I can reproduce the behaviour, with the following additional observations: - It doesn't seem to matter whether true type fonts are enabled or not. - After increasing the font size to medium and opening the browser: -- The (vertical) scroll bar isn't visible, it is possible to scroll using the mouse wheel or cursor keys. -- Increasing the width of the browser so the scroll bar is visible, but not clicking on the scroll bar, scrolling using the mouse wheel or cursor keys still works. -- Once the scroll bar has been clicked on it fails as you describe. HTH, Alistair.

Nov. 12, 2018

Re: [Pharo-dev] Anyone else seen crashes like these ?

by Ben Coman

I meant to also post a link showing the pattern of the recent primitives... https://docs.google.com/spreadsheets/d/1QzY8iL_3kvHJg1xMg1yvCFzDpQf3Tl9zuVk… On Tue, 13 Nov 2018 at 00:50, Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, 12 Nov 2018 at 21:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi, >> >> I run Pharo 7 64-bit on a macOS laptop, where the images are kept running >> across sleep/wake cycles. >> > > Just to confirm, you mean your laptop sleep/wake cycle. > On my Window 10 laptop I do the same quite often with no problems. > > >> For many weeks, it often happens that an image crashes before/after such >> a sleep/wakeup (not all the time, just regularly). >> >> Here is a crash dump from today (fresh image/vm from WE, nothing special >> loaded). >> >> Related to scheduling ? Event handling ? > > > In trying to understand the last few moments, is the recent primitives > list strongly ordered in time?... > Most recent primitives > signal > nowTick > primSignal:atUTCMicroseconds: > wait > millisecondClockValue > @ > actualScreenSize > > > Starting at #actualScreenSize, instrumenting the code by adding... > Transcript crShow: thisContext sender printString. > indicates the following call chain... > DisplayScreen-class>>actualScreenSize > MorphicUIManager>>checkForNewDisplaySize > DisplayScreen class>>checkForNewScreenSize > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldMorph>>doOneCycle > WorldMorph class>>doOneCycle > MorphicUIManager>>spawnNewProcess > > In detail from a static analysis of the code... > > WorldState>>doOneCycleNowFor: > > DisplayScreen class>>checkForNewScreenSize > > MorphicUIManager>>checkForNewDisplaySize > > DisplayScreen-class>>actualScreenSize > PRIMITIVE > < MorphicUIManager>>checkForNewDisplaySize > < DisplayScreen class>>checkForNewScreenSize > < WorldState>>doOneCycleNowFor > < WorldState>>doOneCycleFor: > < WorldMorph>>doOneCycle > < WorldMorph class>>doOneCycle > < MorphicUIManager>>spawnNewProcess > > WorldMorph class>>doOneCycle > > WorldMorph>>doOneCycle > > WorldState>>doOneCycleNowFor: > > WorldState>>interCyclePause: > > Time>>millisecondClockValue PRIMITIVE > < WorldState>>interCyclePause: > > Delay>>schedule > > DelaySemaphoreScheduler>>schedule: > > Semaphore>>wait > PRIMITIVE "readyToSchedule variable" > > Semaphore>>signal > PRIMITIVE "timingSemaphore variable" NOT RECORDED > > maybe context change causes this to be recorded later in "Most > recent primitives" > > > DelayMicrosecondTicker>>waitForUserSignalled:orExpired: waking up from > Semaphore>>wait > the primSignal:atUTCMicroseconds: > PRIMITIVE immediately before the #wait seems to have been logged now in > "Most recent primitives" > > > DelaySemaphoreScheduler>>scheduleAtTimingPriority > > Semaphore>>signal > PRIMITIVE "readyToSchedule variable" seems to have not been recorded in > "Most recent primitives" > > > DelayBasicScheduler>>scheduleAtTimingPriority > < > DelaySemaphoreScheduler>>scheduleAtTimingPriority > < > DelayBasicScheduler>>runBackendLoopAtTimingPriority > > DelayMicrosecondTicker>>nowTick > PRIMITIVE > > Delay>>timingPrioritySignalExpired > > Semaphore>>signal > PRIMITIVE "delaySemaphore variable" CRASH > > Smalltalk stack dump: > 0x7ffee21d7138 M Delay>timingPrioritySignalExpired 0x113e3b138: a(n) > Delay > 0x7ffee21d7170 M [] in > DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority > 0x11453b8c0: a(n) DelaySemaphoreScheduler > 0x1169f51c8 s BlockClosure>ensure: > 0x1169f5828 s > DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority > 0x1169f5c38 s [] in > DelaySemaphoreScheduler(DelayBasicScheduler)>startTimerEventLoopPriority: > 0x1169fae10 s [] in BlockClosure>newProcess > > The only reason I can think that last semaphore call would be a problem is > if variable delaySemaphore was not a Semaphore, > but the C stack backtrace doesn't look like it crashes in the Semaphore > handling. > Its perhaps co-incidental with delay scheduling code is invoked fairly > often, that its the current process when this crash occurs. > > > To hep isolate the failure point, I would considering copying #nowTIck to > a multiple series like... > #nowTick1 > #nowTick2 > #nowTick3 > etc so that all of the sender sites can be made distinct. > And maybe the same for #signal senders within the delay scheduling code. > > One side-curiousity is I can't see where the primitive #@ is being called > from. > Does it indicate some loop as its trying to determine > > To me the "vmIOProcessEvents" in the C backtrace with a fairly deep stack > into the AppKit framework > indicates its related to event handling. > > cheers -ben >

Nov. 12, 2018

Re: [Pharo-dev] Anyone else seen crashes like these ?

by Ben Coman

On Mon, 12 Nov 2018 at 21:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I run Pharo 7 64-bit on a macOS laptop, where the images are kept running > across sleep/wake cycles. > Just to confirm, you mean your laptop sleep/wake cycle. On my Window 10 laptop I do the same quite often with no problems. > For many weeks, it often happens that an image crashes before/after such a > sleep/wakeup (not all the time, just regularly). > > Here is a crash dump from today (fresh image/vm from WE, nothing special > loaded). > > Related to scheduling ? Event handling ? In trying to understand the last few moments, is the recent primitives list strongly ordered in time?... Most recent primitives signal nowTick primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize Starting at #actualScreenSize, instrumenting the code by adding... Transcript crShow: thisContext sender printString. indicates the following call chain... DisplayScreen-class>>actualScreenSize MorphicUIManager>>checkForNewDisplaySize DisplayScreen class>>checkForNewScreenSize WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle WorldMorph class>>doOneCycle MorphicUIManager>>spawnNewProcess In detail from a static analysis of the code... > WorldState>>doOneCycleNowFor: > DisplayScreen class>>checkForNewScreenSize > MorphicUIManager>>checkForNewDisplaySize > DisplayScreen-class>>actualScreenSize PRIMITIVE < MorphicUIManager>>checkForNewDisplaySize < DisplayScreen class>>checkForNewScreenSize < WorldState>>doOneCycleNowFor < WorldState>>doOneCycleFor: < WorldMorph>>doOneCycle < WorldMorph class>>doOneCycle < MorphicUIManager>>spawnNewProcess > WorldMorph class>>doOneCycle > WorldMorph>>doOneCycle > WorldState>>doOneCycleNowFor: > WorldState>>interCyclePause: > Time>>millisecondClockValue PRIMITIVE < WorldState>>interCyclePause: > Delay>>schedule > DelaySemaphoreScheduler>>schedule: > Semaphore>>wait PRIMITIVE "readyToSchedule variable" > Semaphore>>signal PRIMITIVE "timingSemaphore variable" NOT RECORDED maybe context change causes this to be recorded later in "Most recent primitives" > DelayMicrosecondTicker>>waitForUserSignalled:orExpired: waking up from Semaphore>>wait the primSignal:atUTCMicroseconds: PRIMITIVE immediately before the #wait seems to have been logged now in "Most recent primitives" > DelaySemaphoreScheduler>>scheduleAtTimingPriority > Semaphore>>signal PRIMITIVE "readyToSchedule variable" seems to have not been recorded in "Most recent primitives" > DelayBasicScheduler>>scheduleAtTimingPriority < DelaySemaphoreScheduler>>scheduleAtTimingPriority < DelayBasicScheduler>>runBackendLoopAtTimingPriority > DelayMicrosecondTicker>>nowTick PRIMITIVE > Delay>>timingPrioritySignalExpired > Semaphore>>signal PRIMITIVE "delaySemaphore variable" CRASH Smalltalk stack dump: 0x7ffee21d7138 M Delay>timingPrioritySignalExpired 0x113e3b138: a(n) Delay 0x7ffee21d7170 M [] in DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority 0x11453b8c0: a(n) DelaySemaphoreScheduler 0x1169f51c8 s BlockClosure>ensure: 0x1169f5828 s DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority 0x1169f5c38 s [] in DelaySemaphoreScheduler(DelayBasicScheduler)>startTimerEventLoopPriority: 0x1169fae10 s [] in BlockClosure>newProcess The only reason I can think that last semaphore call would be a problem is if variable delaySemaphore was not a Semaphore, but the C stack backtrace doesn't look like it crashes in the Semaphore handling. Its perhaps co-incidental with delay scheduling code is invoked fairly often, that its the current process when this crash occurs. To hep isolate the failure point, I would considering copying #nowTIck to a multiple series like... #nowTick1 #nowTick2 #nowTick3 etc so that all of the sender sites can be made distinct. And maybe the same for #signal senders within the delay scheduling code. One side-curiousity is I can't see where the primitive #@ is being called from. Does it indicate some loop as its trying to determine To me the "vmIOProcessEvents" in the C backtrace with a fairly deep stack into the AppKit framework indicates its related to event handling. cheers -ben

Nov. 12, 2018

Pharo 7 RC - Changing to larger font breaks scrolling in code browsers

by Sven Van Caekenberghe

Hi, Here is an annoying usability bug that I am experiencing and that sometimes drives me nuts. It has been there a while. Take a stock Pharo 7 RC image and don't change any setting. Browse the method #testAsDateAndTime as implemented by DateAndTimeTest. This is a (too) long (test) method. Any long method will do. You can scroll it fine in both the implementors and well as in the full browser. Now switch to 'Medium' sized 'predefined style' Standard Fonts using the Settings Browser. It is now close to impossible to scroll in the implementors or the full browser: not using the scroll bar arrows, not dragging the scroll bar, not clicking above/below the scroll bar, not using the scroll gesture (track pad, mouse pad, wheel), not using cursor keys inside the editor. Scrolling seems to happen automatically and goes on until the top or bottom. Can anyone replicate this ? Sven

Nov. 12, 2018

[Pharo 7.0-dev] Build #1381: 22609-When-we-separate-a-tab-from-the-Welcome-window-you-can-not-close-it

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

There is a new Pharo build available! The status of the build #1381 was: FAILURE. The Pull Request #1973 was integrated: "22609-When-we-separate-a-tab-from-the-Welcome-window-you-can-not-close-it" Pull request url: https://github.com/pharo-project/pharo/pull/1973 Issue Url: https://pharo.fogbugz.com/f/cases/22609 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 12, 2018

Re: [Pharo-dev] Anyone else seen crashes like these ?

by Tim Mackinnon

You didnât say it, but I think implied that this is new to P7? I donât get it on P6, and havenât noticed it in earlier P7 images. But havenât extensively used a newer P7 image. Tim Sent from my iPhone > On 12 Nov 2018, at 21:47, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > >> On Mon, Nov 12, 2018 at 2:37 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> I run Pharo 7 64-bit on a macOS laptop, where the images are kept running across sleep/wake cycles. >> >> For many weeks, it often happens that an image crashes before/after such a sleep/wakeup (not all the time, just regularly). >> >> Here is a crash dump from today (fresh image/vm from WE, nothing special loaded). >> >> Related to scheduling ? Event handling ? >> > > Hi, > > I switched to an macOS at the beginning of October and since I often > have this kind of behavior. > >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr >

Nov. 12, 2018

[Pharo 7.0-dev] Build #1380: 22206-NautilusRefactoring-should-have-the-tests-in-a-separate-package

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

There is a new Pharo build available! The status of the build #1380 was: FAILURE. The Pull Request #1974 was integrated: "22206-NautilusRefactoring-should-have-the-tests-in-a-separate-package" Pull request url: https://github.com/pharo-project/pharo/pull/1974 Issue Url: https://pharo.fogbugz.com/f/cases/22206 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 12, 2018

[Pharo 7.0-dev] Build #1379: Added Interval>>sort: method that raises a "you can not sort an interâ¦

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

There is a new Pharo build available! The status of the build #1379 was: SUCCESS. The Pull Request #1922 was integrated: "Added Interval>>sort: method that raises a "you can not sort an interâ¦" Pull request url: https://github.com/pharo-project/pharo/pull/1922 Issue Url: https://pharo.fogbugz.com/f/cases/22588 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 12, 2018

Re: [Pharo-dev] Anyone else seen crashes like these ?

by Cyril Ferlicot

On Mon, Nov 12, 2018 at 2:37 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > I run Pharo 7 64-bit on a macOS laptop, where the images are kept running across sleep/wake cycles. > > For many weeks, it often happens that an image crashes before/after such a sleep/wakeup (not all the time, just regularly). > > Here is a crash dump from today (fresh image/vm from WE, nothing special loaded). > > Related to scheduling ? Event handling ? > Hi, I switched to an macOS at the beginning of October and since I often have this kind of behavior. > > -- Cyril Ferlicot https://ferlicot.fr

Nov. 12, 2018

Anyone else seen crashes like these ?

by Sven Van Caekenberghe

Hi, I run Pharo 7 64-bit on a macOS laptop, where the images are kept running across sleep/wake cycles. For many weeks, it often happens that an image crashes before/after such a sleep/wakeup (not all the time, just regularly). Here is a crash dump from today (fresh image/vm from WE, nothing special loaded). Related to scheduling ? Event handling ?

Nov. 12, 2018

Re: [Pharo-dev] Better management of encoding of environment variables

by Ben Coman

On Mon, 12 Nov 2018 at 18:02, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi all, > > following the meeting we had here @Inria headquarters, I'll be backporting > some of the improvements we did in the launcher this last month regarding > the encoding of environment variables. > > I've opened for this issue https://pharo.fogbugz.com/f/cases/22658/ > > We have already studied possible alternatives with Pablo and Christophe > and we have some conclusions and we propose some changes: > > API Proposal for OSEnvironment > ========================= > > > - > *at: aVariableName * > > Gets the String value of an environment variable called `aVariableName` > It is the system reponsibility to manage the encoding. > Rationale: A common denominator for all platforms providing an already > decoded string, because windows does not (compared to *nix systems) provide > a encoded byte representation of the value. Windows has instead its own > wide string representation. > > - *[optionally] rawAt: anEncodedVariableName* > > Gets the Byte value of an environment variable called > `anEncodedVariableName`. > It is the user responsibility to encode and decode argument and return > values in the encoding of this preference. > Rationale: Some systems may want to have the liberty to use different > encodings, or even to put binary data in the variables. > > - *[optionally] at: aVariableName encoding: anEncoding* > > Gets the value of an environment variable called `aVariableName` using > `anEncoding` to encode/decode arguments and return values. > Rationale: *xes could potentially use different encodings for their > environment variables or even use different encodings in different parts of > their file system. > > Other Implementation details > ========================= > > - VM primitives returning paths Strings should be carefuly managed to > decode them, since they are actually C strings (so byte arrays) disguised > as ByteStrings. > - Windows requires calling the right *Wide version of the functions > from C, plus the correct encoding routine. This could be implemented as an > FFI call or by modifying the VM to do it properly instead of calling the > Ascii version > > I haven't been using environment variables a lot so I don't have a strong technical opinion (although at a glance it makes reasonable sense). But I wanted to say I really like the way you've presented your offline discussion, conclusions and proposal. Thanks. cheers -ben

Nov. 12, 2018

[Pharo 7.0-dev] Build #1378: 22651-URL-color-is-hardcoded-in-welcome-window

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

There is a new Pharo build available! The status of the build #1378 was: FAILURE. The Pull Request #1972 was integrated: "22651-URL-color-is-hardcoded-in-welcome-window" Pull request url: https://github.com/pharo-project/pharo/pull/1972 Issue Url: https://pharo.fogbugz.com/f/cases/22651 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 12, 2018

[Pharo 7.0-dev] Build #1377: 22649-Remove DelaySpinScheduler

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

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

Nov. 12, 2018

Better management of encoding of environment variables

by Guillermo Polito

Hi all, following the meeting we had here @Inria headquarters, I'll be backporting some of the improvements we did in the launcher this last month regarding the encoding of environment variables. I've opened for this issue https://pharo.fogbugz.com/f/cases/22658/ We have already studied possible alternatives with Pablo and Christophe and we have some conclusions and we propose some changes: API Proposal for OSEnvironment ========================= - *at: aVariableName * Gets the String value of an environment variable called `aVariableName` It is the system reponsibility to manage the encoding. Rationale: A common denominator for all platforms providing an already decoded string, because windows does not (compared to *nix systems) provide a encoded byte representation of the value. Windows has instead its own wide string representation. - *[optionally] rawAt: anEncodedVariableName* Gets the Byte value of an environment variable called `anEncodedVariableName`. It is the user responsibility to encode and decode argument and return values in the encoding of this preference. Rationale: Some systems may want to have the liberty to use different encodings, or even to put binary data in the variables. - *[optionally] at: aVariableName encoding: anEncoding* Gets the value of an environment variable called `aVariableName` using `anEncoding` to encode/decode arguments and return values. Rationale: *xes could potentially use different encodings for their environment variables or even use different encodings in different parts of their file system. Other Implementation details ========================= - VM primitives returning paths Strings should be carefuly managed to decode them, since they are actually C strings (so byte arrays) disguised as ByteStrings. - Windows requires calling the right *Wide version of the functions from C, plus the correct encoding routine. This could be implemented as an FFI call or by modifying the VM to do it properly instead of calling the Ascii version

Nov. 12, 2018

Esteban's ChangeLog week of 5 November 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 5 November 2018 to 11 November 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=5/11/2018&to=11/11/2018 ChangeLog ========= 5 November 2018: ---------------- * I just [announced](http://forum.world.st/ANN-Pharo-v7-0-0-rc1-released-td5088221.html) Pharo v7.0.0-rc1. Now the real work begins... :P * I worked on [case: 22628](https://pharo.fogbugz.com/f/cases/22628): merge latest FFI-Kernel changes. Thing is, now there is some overlapping between FFI-Kernel and UnifiedFFI, because they changed it in some things we already solved in UFFI, but well... we will have to see this in the future :) * I made a small PR to add a fix that Eliot contributed to it: [https://github.com/pharo-vcs/tonel/pull/60](https://github.com/pharo-vcs/to… . Is an error that happens when a snapshot contains *only* method extensions. cheers! Esteban

Nov. 12, 2018

Re: [Pharo-dev] Excel export with Tabular

by Eric Gade

I want to second support for this effort. I had a freelance project a few months back that had a need to generate formatted Excel documents from external API data. It also needed an easy to use GUI for it's users. At the time I desperately wanted to use Pharo (since RAD tools on personal computers have sadly become an endangered species). Instead I was forced to make an Electronic app. In short, there is a real need for this out there and I feel like it goes understated. On Sun, Nov 11, 2018, 16:50 Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Hans-Martin, > > This is great. I use Tabular too and was missing active > development/maintenance. It would be very good to see this project move > forward. It is quite important/useful in enterprise contexts. > > Thx, > > Sven > > PS: where did you commit the changes ? any chance of moving it to GitHub > (too) ? > > > On 11 Nov 2018, at 22:16, Hans-Martin <pharo-dev(a)fam-mosner.de> wrote: > > > > Hello folks, > > I have a need for creating excel files with more than 3 worksheets, so I > > took the Tabular code and beefed up the exporter a little. It does handle > > more worksheets now, uses XMLWriter to create all the ZIP members, and is > > properly named now (the class was called TabularXSLXExport, note swapped > S > > and L). > > Some tests have been added, there are a number of items that I plan to > to as > > time allows: > > - Add (possibly limited) support for styles and formulas which I > > specifically need for the project I'm working on so I could write files > with > > the desired layout and functionality. > > - Add support for reading more aspects of XLSX files, preferrably as > much as > > needed to be able to read and write most files without loss. > > - Add rendering, maybe at the basic morphic level, maybe using something > > else as I'm not really up-to-date regarding the developments in Pharo. > > - Add formula evaluation. > > - Add editing capabilites to have a fully functional spreadsheet (really > far > > off). > > > > Cheers, > > Hans-Martin > > > > > > > > -- > > Sent from: > http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > > > >

Nov. 11, 2018

Re: [Pharo-dev] Excel export with Tabular

by Sven Van Caekenberghe

Hi Hans-Martin, This is great. I use Tabular too and was missing active development/maintenance. It would be very good to see this project move forward. It is quite important/useful in enterprise contexts. Thx, Sven PS: where did you commit the changes ? any chance of moving it to GitHub (too) ? > On 11 Nov 2018, at 22:16, Hans-Martin <pharo-dev(a)fam-mosner.de> wrote: > > Hello folks, > I have a need for creating excel files with more than 3 worksheets, so I > took the Tabular code and beefed up the exporter a little. It does handle > more worksheets now, uses XMLWriter to create all the ZIP members, and is > properly named now (the class was called TabularXSLXExport, note swapped S > and L). > Some tests have been added, there are a number of items that I plan to to as > time allows: > - Add (possibly limited) support for styles and formulas which I > specifically need for the project I'm working on so I could write files with > the desired layout and functionality. > - Add support for reading more aspects of XLSX files, preferrably as much as > needed to be able to read and write most files without loss. > - Add rendering, maybe at the basic morphic level, maybe using something > else as I'm not really up-to-date regarding the developments in Pharo. > - Add formula evaluation. > - Add editing capabilites to have a fully functional spreadsheet (really far > off). > > Cheers, > Hans-Martin > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Nov. 11, 2018

Excel export with Tabular

by Hans-Martin

Hello folks, I have a need for creating excel files with more than 3 worksheets, so I took the Tabular code and beefed up the exporter a little. It does handle more worksheets now, uses XMLWriter to create all the ZIP members, and is properly named now (the class was called TabularXSLXExport, note swapped S and L). Some tests have been added, there are a number of items that I plan to to as time allows: - Add (possibly limited) support for styles and formulas which I specifically need for the project I'm working on so I could write files with the desired layout and functionality. - Add support for reading more aspects of XLSX files, preferrably as much as needed to be able to read and write most files without loss. - Add rendering, maybe at the basic morphic level, maybe using something else as I'm not really up-to-date regarding the developments in Pharo. - Add formula evaluation. - Add editing capabilites to have a fully functional spreadsheet (really far off). Cheers, Hans-Martin -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 11, 2018