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

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

by Norbert Hartl

Hi > Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Hi > > Pay attention the following email is not nice and politically correct > but it is important for the speed of improvements in Pharo. > thanks for the disclaimer. It is important. I copy that because mine might be not political correct, too. > I think that we are doing our best when dealing with subproject code. > Now if we are forced to publish each little changes > on each subproject and wait that something gets integrated into each > subproject, then I would prefer to stop Pharo and do something else. > We cannot ask someone to stop in the middle of a massive super boring > and feel like shit cleaning in addition to stop and > please publish a PR and wait that it gets integrated and wait that > Pharo integrates the new version. > Let us be a bit serious and pro here. > I know this. And Iâm taking it serious because I want to talk about it. If you decide that you rather be offended then talk please do. I find it annoying that a lot of topics are washed away because someone is offended. That is just another way of killing communication although it is a state-of-the-art these days. > Or we should drop subprojects. Because changing Pharo is getting a > painful. Imagine just a change cross cutting several subprojects. > For example, I did not fix the use of deprecated classes in Iceberg > because I got distracted by the where is the project hosted and I was > not connected on a good web connection. I changed calypso and > published to calypso but if the feedback loop is too long it means > that > we will prefer to work on our own projects (because we have also our > own projects and there velocity is high and attractive). > > I think that with github support this is simple to get the changes. > Finally I heard that large companies developing large projects using > github are managing one single repo: no subprojects, with their own PR > and sync. And us little guys with our super clever brains we will > succeed adding more constraints on the table. > How bold are we. I'm impressed by such level of arrogance. This is why > I do not like that Pharo gets managed in various repo > because it kills us. > Actually I was inquiring what everyone is doing to circumvent those problems (!!!). I have the same situation in my company. Iâm the one that is reluctant to go to monorepo because I donât like my code jailed in a project. But the effort we have to take in order to organize a stable and development version with a lot of external projects is killing us. So can we please talk about it? Pleeeeeaaassseee??? Norbert > Stef > On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> >>> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> >>> >>>> 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 ? >>> >> The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch. >> >> Norbert >> >> >> >> >> >

Nov. 2, 2018

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

by Stephane Ducasse

Hi Pay attention the following email is not nice and politically correct but it is important for the speed of improvements in Pharo. I think that we are doing our best when dealing with subproject code. Now if we are forced to publish each little changes on each subproject and wait that something gets integrated into each subproject, then I would prefer to stop Pharo and do something else. We cannot ask someone to stop in the middle of a massive super boring and feel like shit cleaning in addition to stop and please publish a PR and wait that it gets integrated and wait that Pharo integrates the new version. Let us be a bit serious and pro here. Or we should drop subprojects. Because changing Pharo is getting a painful. Imagine just a change cross cutting several subprojects. For example, I did not fix the use of deprecated classes in Iceberg because I got distracted by the where is the project hosted and I was not connected on a good web connection. I changed calypso and published to calypso but if the feedback loop is too long it means that we will prefer to work on our own projects (because we have also our own projects and there velocity is high and attractive). I think that with github support this is simple to get the changes. Finally I heard that large companies developing large projects using github are managing one single repo: no subprojects, with their own PR and sync. And us little guys with our super clever brains we will succeed adding more constraints on the table. How bold are we. I'm impressed by such level of arrogance. This is why I do not like that Pharo gets managed in various repo because it kills us. Stef On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > > > > >> 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 ? > > > The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch. > > Norbert > > > > >

Nov. 2, 2018

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

by Norbert Hartl

> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> 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 ? > The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch. Norbert

Nov. 2, 2018

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

by Norbert Hartl

Hi, > Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> 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 ? > I think I have to. Usually it is not possible to load something from bleedingEdge and Zinc is used all over the place. But as it is you I change it ;) Norbert

Nov. 2, 2018

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