- Pharo-dev - lists.pharo.org

FFI test Smalltalk code

by Eliot Miranda

Hi All, I'm looking at a bug with the Win64 FFI when there are more than four arguments. The test functions are in platforms/Cross/plugins/SqueakFFIPrims/sqFFITestFuncs.c and the SUnit code is in FFI-Tests, e.g. on http://source.squeak.org/FFI. But whereas sqFFITestFuncs.c already contains functions such as ffiTestInts8, ffiTestFloats7, ffiTestFloats13, there are no test for these in FFI-Tests. Can anyone point me to such tests, and/or commit them to FFI-Tests on http://source.squeak.org/FFI? AdvThanksance _,,,^..^,,,_ best, Eliot

Nov. 2, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Sven Van Caekenberghe

> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Norbert, > >> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it. > > The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble. Norbert, I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more. Could you please test ? Thx, Sven

Nov. 1, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Sven Van Caekenberghe

Norbert, > On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it. The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.

Nov. 1, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Sven Van Caekenberghe

> On 1 Nov 2018, at 14:38, Norbert Hartl <norbert(a)hartl.name> wrote: > > I asked this before because I donât get it. External packages like Zinc seem to be modified when integrated into pharo. When a new version of Zinc is integrated, it is done as-is. The problem is that people keep on changing things afterwards. > Looking at the changes between to newest Zinc from Svenâs repository and the one in pharo there are a few differences. As an example there is > > ZnCharacterReadWriteStream>>#tab > writeStream tab > > Where is this method added? I don't know, this is the first time I see that particular one. > Are the changes pushed back to Sven? I do this all by hand myself, afterwards. It is sometimes quite a bit of annoying work. > In my project I use Zinc-REST. So I need to add the repository for Zinc and load the REST group. When this is loaded it pulls in the other Zinc packages which removes the methods like the one above and my image gets stuck because Epicea relies on that method and I get a debugger. > So at the moment I can only create a new image when I disable Epicea. Yes, this is really annoying. > Why is it done that way? Best would be to use the version from Sven and make changes there. If that is not possible it would be good to use an extra package that does extension methods to Zinc. But this way is asking for trouble IMHO. > > Norbert Yes, I would also prefer things to go to Zn first. But then it takes longer for people to see their changes in the base image. Now to be fair, the new file/stream changes did require a shorter feedback loop in pharo itself. I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it. Sven

Nov. 1, 2018

Re: [Pharo-dev] Source/changes file suffixes constants

by Sven Van Caekenberghe

Hi, > On 1 Nov 2018, at 17:59, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven, > > On Wed, 31 Oct 2018 at 16:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> Current FileStream holds (in the protocol 'file reader services') some constants regarding source/changes file suffixes. >> >> Where should we move these to (as FileStream is deprecated) ? >> >> There is a class SourceFile, there is PharoFilesOpener, neither seems to fit that well. >> >> Suggestions ? > > Can you clarify why you think SourcFile is not a good candidate? The name is of course good, but the functionality is not really related. If others think this is a good place, then it is OK for me too. > #changesFileSuffixes, #isChangesFileSuffix:, #isSourceFileSuffix:, > #sourceFileSuffixes all relate to specifying source files, so could > possibly go to SourceFile. OK > #fileIn: should be deprecated. FileReference>>fileIn provides the same > functionality. Yes > #removeLineFeeds: seems to be unused. Deprecate as well? Yes > Cheers, > Alistair

Nov. 1, 2018

Re: [Pharo-dev] Source/changes file suffixes constants

by Alistair Grant

Hi Sven, On Wed, 31 Oct 2018 at 16:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > Current FileStream holds (in the protocol 'file reader services') some constants regarding source/changes file suffixes. > > Where should we move these to (as FileStream is deprecated) ? > > There is a class SourceFile, there is PharoFilesOpener, neither seems to fit that well. > > Suggestions ? Can you clarify why you think SourcFile is not a good candidate? #changesFileSuffixes, #isChangesFileSuffix:, #isSourceFileSuffix:, #sourceFileSuffixes all relate to specifying source files, so could possibly go to SourceFile. #fileIn: should be deprecated. FileReference>>fileIn provides the same functionality. #removeLineFeeds: seems to be unused. Deprecate as well? Cheers, Alistair

Nov. 1, 2018

Re: [Pharo-dev] ClyMethodGroup>>#fileOut dead code ?

by Esteban Lorenzano

Can you add an issue into: https://github.com/pharo-ide/Calypso Thanks! Esteban > On 31 Oct 2018, at 19:57, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Sven. > > It is not dead. It is here to file out any method group including normal protocols. > It was copied from SystemOrganizer>>fileOutCategory:. Now it needs to be fixed in Pharo 7 and it would be nice to have it in better form > > ÑÑ, 31 Ð¾ÐºÑ. 2018 Ð³. Ð² 15:39, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: > Hi, > > ClyMethodGroup>>#fileOut seems like dead code (it sends #trailer to a WriteStream which DNUs). It also uses the deprecated FileStream. > > Can it be removed ? > > Sven

Nov. 1, 2018

Cannot use Zinc in Pharo7 anymore

by Norbert Hartl

I asked this before because I donât get it. External packages like Zinc seem to be modified when integrated into pharo. Looking at the changes between to newest Zinc from Svenâs repository and the one in pharo there are a few differences. As an example there is ZnCharacterReadWriteStream>>#tab writeStream tab Where is this method added? Are the changes pushed back to Sven? In my project I use Zinc-REST. So I need to add the repository for Zinc and load the REST group. When this is loaded it pulls in the other Zinc packages which removes the methods like the one above and my image gets stuck because Epicea relies on that method and I get a debugger. So at the moment I can only create a new image when I disable Epicea. Why is it done that way? Best would be to use the version from Sven and make changes there. If that is not possible it would be good to use an extra package that does extension methods to Zinc. But this way is asking for trouble IMHO. Norbert

Nov. 1, 2018

glamorous toolkit alpha.2

by Tudor Girba

Hi, Glamorous Toolkit has evolved quite a bit over the past months, and we now would like to announce that we reached alpha.2 version. It runs on top of Pharo 7: feenk.com/gt There quite a number of new things. Some highlights are: - We added extensive documentation for GT, Bloc and Brick. By running "GtWorld openTourâ you essentially transform the image into an elaborate wiki. - We worked on Coder, a new set of tools that are dedicated for affecting code. For example, in the picture below we see an editor on embedded examples that can be edited and run independently. And this one shows how we can visualize and edit the result of querying. Just a note: To make Coder work the way we want, we extended Brick with several widgets, and enhanced significantly the linear and grid layouts. - We added the first version of xdoc in order to serialize the Playground every time you evaluate something. As always, we are looking forward to your feedback. Have fun, The feenk team -- www.feenk.com -- www.feenk.com "Every thing should have the right to be different."

Oct. 31, 2018

Re: [Pharo-dev] [ANN] The STON Specification

by David T. Lewis

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/lastSuccessf… > > 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 > > > > >

Oct. 31, 2018