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

Re: [Pharo-dev] Now this is fun ...

by phil＠highoctane.be

PR bomb... fork all his repos and issue gazillons of PRs. Or maybe ask Github for turning ownership to us. Phil On Mon, Nov 5, 2018, 17:19 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com wrote: > :) > > I think nobody expects Pharo to be : https://github.com/pharo-project > > but like these: > > https://github.com/perl -> The Perl Programming Language > https://github.com/ruby -> The Ruby Programming Language > https://github.com/python -> The Python Programming Language > > More fun: > > https://github.com/smalltalk -> Mareike Hybsier > https://github.com/lisp -> James Anderson > https://github.com/rust -> Shinichiro OGAWA > https://github.com/cpp -> Stefan Herr > https://github.com/java -> A product manager > > > > El lun., 5 nov. 2018 a las 12:44, Sven Van Caekenberghe > (<sven(a)stfx.eu>) escribiÃ³: > > > > https://github.com/pharo > > > > ;-) > > > > > >

Nov. 5, 2018

Re: [Pharo-dev] Now this is fun ...

by Ben Coman

On Mon, 5 Nov 2018 at 23:43, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > https://github.com/pharo > > ;-) > Beat us to it in 2011. But with only 4 repositories, I wonder did anyone politely reach out to describe out community and ask if we might allowed to adopt that url? You can't know anyone's situation and philosophy until you ask them. I could do it. But better we don't all rush to do it and overwhelm him. cheers -ben

Nov. 5, 2018

Re: [Pharo-dev] Now this is fun ...

by HernÃ¡n Morales Durand

:) I think nobody expects Pharo to be : https://github.com/pharo-project but like these: https://github.com/perl -> The Perl Programming Language https://github.com/ruby -> The Ruby Programming Language https://github.com/python -> The Python Programming Language More fun: https://github.com/smalltalk -> Mareike Hybsier https://github.com/lisp -> James Anderson https://github.com/rust -> Shinichiro OGAWA https://github.com/cpp -> Stefan Herr https://github.com/java -> A product manager El lun., 5 nov. 2018 a las 12:44, Sven Van Caekenberghe (<sven(a)stfx.eu>) escribiÃ³: > > https://github.com/pharo > > ;-) > >

Nov. 5, 2018

Re: [Pharo-dev] [ANN] Iceberg v1.3.1

by HernÃ¡n Morales Durand

Hi Cyril, Does the update apply to Pharo 6.1? Cheers, HernÃ¡n El lun., 5 nov. 2018 a las 10:16, Cyril Ferlicot (<cyril.ferlicot(a)gmail.com>) escribiÃ³: > > Hello! > > This week we are releasing the version v1.3 of Iceberg. > (https://github.com/pharo-vcs/iceberg/releases/tag/v1.3.0 > +https://github.com/pharo-vcs/iceberg/releases/tag/v1.3.1) > > This version will be available after we merge this PR: > > https://github.com/pharo-project/pharo/pull/1951 > > This release contains some new features such as the support of self > hosted gitlab, integration with github, etc. > It also contains multiple bug fixes, cleanups and enhancements. > > On the CI part, Guille made the Appveyor build green! This will > increase the stability of the windows support. > > Thanks to all contributors. > > Enjoy! > > Full changelog: > > Features > > #1021 Self hosted gitlab support > #1027 Improved new tag dialog to generate semantic versionning tags > #1044 Show a button "View on Github" when creating a PR > #1008 Add "create branch from GitHub issue" option > #1048 Add commands to open remotes on Github > #1010 Add menu entry in extras to force calculate diff > > Bug corrections > > #975 Metacello asks too many times what to install when there are > conflicting versions > #980 Iceberg should Identify better the packages and the normal files > #982 The Edit Project should have a Warning if it will affect the packages > #986 Iceberg does not realize changes in extended classes > #999 Pulling and pushing to a gitolite server asks password > #984 Conversion to Tonel generates corrupted .properties > #1041 Filter in repository view don't work with capital letters > #1019 Metacello Integration leaves Monticello leftover repositories > #859 Creating a branch and pushing does not sets the upstream > #1043 Packages starting with lowercase not recognized > #991 Error on right click in the project editon wizard > #775 Reviewing a PR is broken > #1036 Debugger if we try to merge without selecting a branch > #1064 Fix failing tests regarding clean code in Pharo > > Enhancements > > #988 Iceberg should load the packages in a single MCLoader (This will > make the loads of packages atomic) > #1001 Use "instance creation" instead of "instance-creation" for > method protocol name > #1004 Use displayScaleFactor in UI > #977 Add ToolTip help to the Commands > #1030 Better support for binary files > #1034 SSH passphrase is now hidden > > Cleanups > > #1018 Iceberg UI relies on deprecated classes from Spec and Commander > #1051 Clean useless huge hierarchy in Github plugin UI > > Infrastructure Enhancements > > #1023 Fix CI for windows > > -- > Cyril Ferlicot > https://ferlicot.fr >

Nov. 5, 2018

Now this is fun ...

by Sven Van Caekenberghe

https://github.com/pharo ;-)

Nov. 5, 2018

[ANN] Pharo v7.0.0-rc1 released!

by Esteban Lorenzano

Greetings! Iâm announcing today we reach Pharo 7.0.0-rc1! This is the first step to release a definitive version, and while we will continue integrating bug fixes, API change Pull Requests will be delayed until the open of Pharo 8.0.0 development. Now, you would wonder what is the ChangeLog of this releaseâ¦ and answer is we still do not have one (btw, we should find a way to automate this). Anywayâ¦ we are very close to release now :) Please download, test, report issues. Esteban

Nov. 5, 2018

[Pharo 7.0-dev] Build #1362: 22627-Integrate-Iceberg-131

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

There is a new Pharo build available! The status of the build #1362 was: FAILURE. The Pull Request #1951 was integrated: "22627-Integrate-Iceberg-131" Pull request url: https://github.com/pharo-project/pharo/pull/1951 Issue Url: https://pharo.fogbugz.com/f/cases/22627 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 5, 2018

Re: [Pharo-dev] [ANN] 22477 DelayScheduler cleanup and refactoring [was: Where do we go now ?]

by Ben Coman

On Mon, 5 Nov 2018 at 20:02, Stephan Eggermont <stephan(a)stack.nl> wrote: > Ben Coman <btc(a)openinworld.com> wrote: > > On Fri, 13 Apr 2018 at 13:56, Benoit St-Jean via Pharo-users < > > pharo-users(a)lists.pharo.org> wrote: > > > > What is the current status of this? DelaySpinScheduler is default in my > recent Pharo 7 images and makes my images unusable on Ubuntu 18.04LTS. > The refactoring was enabled a month ago. DelaySemaphoreScheduler in the refactored hierarchy was made default so that DelaySpinScheduler could remain in place in the old hierarchy . https://github.com/pharo-project/pharo/blame/development/src/Kernel/Delay.c… On discord you mention that DelaySpinScheduler was the default in build 1358. But with PharoLauncher I just downloaded "Pharo-7.0.0-alpha.build.1358.sha.f9325e7.arch.32bit" and for me it shows DelaySemaphoreScheduler is the default. Evaluating ```Delay delaySchedulerClass``` ==> "DelaySemaphoreScheduler" and the process browser shows... [image: DelayScheduler-build-71358.png] So I'm curious how DelaySpinScheduler became enabled for you? cheers -ben P.S. a case was found where a process running at highestPriority (the same as the delay scheduling loop) that called Delay>>schedule: twice would lock DelaySpinScheduler - since the delay scheduling loop would not get an opportunity to process & clear the transfer-variable "delayToStart". I'd always worked with the assumption that the delay scheduling loop was the only process running at highest priority. DelaySemaphoreScheduler works fine with multiple highestPriority processes, so it will be the default going forward.

Nov. 5, 2018

[ANN] Iceberg v1.3.1

by Cyril Ferlicot

Hello! This week we are releasing the version v1.3 of Iceberg. (https://github.com/pharo-vcs/iceberg/releases/tag/v1.3.0 +https://github.com/pharo-vcs/iceberg/releases/tag/v1.3.1) This version will be available after we merge this PR: https://github.com/pharo-project/pharo/pull/1951 This release contains some new features such as the support of self hosted gitlab, integration with github, etc. It also contains multiple bug fixes, cleanups and enhancements. On the CI part, Guille made the Appveyor build green! This will increase the stability of the windows support. Thanks to all contributors. Enjoy! Full changelog: Features #1021 Self hosted gitlab support #1027 Improved new tag dialog to generate semantic versionning tags #1044 Show a button "View on Github" when creating a PR #1008 Add "create branch from GitHub issue" option #1048 Add commands to open remotes on Github #1010 Add menu entry in extras to force calculate diff Bug corrections #975 Metacello asks too many times what to install when there are conflicting versions #980 Iceberg should Identify better the packages and the normal files #982 The Edit Project should have a Warning if it will affect the packages #986 Iceberg does not realize changes in extended classes #999 Pulling and pushing to a gitolite server asks password #984 Conversion to Tonel generates corrupted .properties #1041 Filter in repository view don't work with capital letters #1019 Metacello Integration leaves Monticello leftover repositories #859 Creating a branch and pushing does not sets the upstream #1043 Packages starting with lowercase not recognized #991 Error on right click in the project editon wizard #775 Reviewing a PR is broken #1036 Debugger if we try to merge without selecting a branch #1064 Fix failing tests regarding clean code in Pharo Enhancements #988 Iceberg should load the packages in a single MCLoader (This will make the loads of packages atomic) #1001 Use "instance creation" instead of "instance-creation" for method protocol name #1004 Use displayScaleFactor in UI #977 Add ToolTip help to the Commands #1030 Better support for binary files #1034 SSH passphrase is now hidden Cleanups #1018 Iceberg UI relies on deprecated classes from Spec and Commander #1051 Clean useless huge hierarchy in Github plugin UI Infrastructure Enhancements #1023 Fix CI for windows -- Cyril Ferlicot https://ferlicot.fr

Nov. 5, 2018

Re: [Pharo-dev] [ANN] 22477 DelayScheduler cleanup and refactoring [was: Where do we go now ?]

by Stephan Eggermont

Ben Coman <btc(a)openinworld.com> wrote: > On Fri, 13 Apr 2018 at 13:56, Benoit St-Jean via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > What is the current status of this? DelaySpinScheduler is default in my recent Pharo 7 images and makes my images unusable on Ubuntu 18.04LTS. Stephan

Nov. 5, 2018

[Pharo 7.0-dev] Build #1361: 22620-Move-zippedunzipped-from-String-to-ByteArray

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

There is a new Pharo build available! The status of the build #1361 was: FAILURE. The Pull Request #1947 was integrated: "22620-Move-zippedunzipped-from-String-to-ByteArray" Pull request url: https://github.com/pharo-project/pharo/pull/1947 Issue Url: https://pharo.fogbugz.com/f/cases/22620 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 5, 2018

[Pharo 7.0-dev] Build #1360: 22625-FileReferencenextVersion-gets-stuck-at-11

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

There is a new Pharo build available! The status of the build #1360 was: SUCCESS. The Pull Request #1950 was integrated: "22625-FileReferencenextVersion-gets-stuck-at-11" Pull request url: https://github.com/pharo-project/pharo/pull/1950 Issue Url: https://pharo.fogbugz.com/f/cases/22625 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 5, 2018

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

by Stephan Eggermont

Tim Mackinnon <tim(a)testit.works> wrote: > > In retrospect, Iâm wondering if successful projects that have proved > integration usefulness should be moved into the core repo? > (Iceberg/Calypso?) or are we missing something to help easily track the > journey of a multi faceted change (although this sounds overkill?). Or > are there sprint days to try and knock these things through easily with > everyone on board to do it together? > > We are sort of damned if you do and damned if you donât. But certainly we > want to endure that progress can be made without losing the will to contribute. > Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter. With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well. Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints. With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo. With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable. So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate. Is this helpful? Stephan

Nov. 5, 2018

[Pharo 7.0-dev] Build #1359: 22614-Integrate-Calypso-v0120

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

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

Nov. 5, 2018

Esteban's ChangeLog week of 29 October 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 29 October 2018 to 4 November 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=29/10/2018&to=4/11/2018 ChangeLog ========= 29 October 2018: ---------------- * I made a PR to update [Calypso in Pharo 7 to version 0.12.0](https://github.com/pharo-project/pharo/pull/1943). While this should be very easy, in case of Calypso it is a but harder because of its dependency graph, that looks a bit like this : Calypso ClassAnnotation Commander ClassAnnotation SystemCommands Commander ClassAnnotationAnyway, in the medium term, I want to create a tool to do "chained-releases", which is not so easy because we need to modify baselines and do commits, pushs and tags. But it will be possible to do :) cheers! Esteban

Nov. 5, 2018

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

by Sven Van Caekenberghe

I think we all want the same thing: being able to move quickly. It is just not clear how to do that. I saw that you tried a complex scenario in https://pharo.manuscript.com/f/cases/22626/Should-not-hardcode-CmdCommandAb… - I would not even known how to do that, I think. > On 4 Nov 2018, at 15:35, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Just to share my pain with you. Try to change something in the API of Commander? > I think that it will be nearly impossible. > Because Iceberg/Calypso depend on Commander and they are all managed > in different repositories. > So it means > - fork each > - probably introduce automatic deprecation > - do a PR for each of the subprojects (it means identify for each one > if we should work on dev or master and being able to checkout > the correct version which is not always possible) > - then waits.....that may be each of the PR got integrated > - now you lost total focus > - if one day you recover what you were doing then and only then you > may finish your change. > > Good luck. > > So to me the message is clear: stay away. > And this is what I'm doing. > We are damaging our agility on the altar of a pseudo modularity. > > So this is why I will focus on my tiny, uninteresting side projects. > Stef > On Sun, Nov 4, 2018 at 3:14 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi Sven >> >> I agree with you. Ideally we would like to have much better tooling >> and process. >> Now the last time we discussed with Guille and Pablo about it: they >> estimated that this is over one year of work. >> And right now we do not have this engineering time to invest on this >> because other fronts need to be addressed. >> Still this is really slowing us. This is simple: I stopped thinking to >> improve something that touches external packages. >> So I will not work on the trivial changes that would improve Calypso/Iceberg. >> Why? Because this is tedious, boring, not rewarding. >> So yes we can do easily with iceberg simple fix on not external >> packages but as soon as >> - you need to load latest dev version (which can be a different one >> than the current one) >> - update your repo >> - fix >> - do a PR >> - .... wait for its integration >> >> So at the end we as a community can ask ourselves what is the reward >> model for such shitty work? >> And also what are we ready to give so that Pharo maintainers do such boring job. >> >> Right now without really doing it consciously I see myself doing >> either stupid fix or working on side projects >> and this is not a good long term approach because the core of Pharo >> needs a lot of work. >> >> Stef >> On Fri, Nov 2, 2018 at 12:24 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>> >>>> On 2 Nov 2018, at 12:01, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> 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??? >>> >>> It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers. >>> >>> I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos. >>> >>> I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions. >>> >>>> 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. 4, 2018

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

by Sven Van Caekenberghe

> On 4 Nov 2018, at 00:48, Shaping <shaping(a)uurda.org> wrote: > > Can STON be extended to handle Doubles and ArbitraryPrecisionFloats? Being born from a language with a rich numerical hierarchy with fluent, mostly transparent conversions, Smalltalk, STON is deliberately a bit vague on precision and range. Integers, fractions and scaled decimals are infinite precision. Float are doubles, but could be higher precision/range: the number reader just does the calculations with the different parts, assuming some floating point number will come out. Each implementation can react based on its own limitations. > 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> > 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 >> >> >> >> >> > > > > >

Nov. 4, 2018

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

by Tim Mackinnon

Yes this is an emerging problem - I had a similar thing trying to add better navigation support to pharo7 as my change touched core and Calypso, so you had to get something into core and then loop back to get it approved in Calypso (a few weeks later). In retrospect, Iâm wondering if successful projects that have proved integration usefulness should be moved into the core repo? (Iceberg/Calypso?) or are we missing something to help easily track the journey of a multi faceted change (although this sounds overkill?). Or are there sprint days to try and knock these things through easily with everyone on board to do it together? We are sort of damned if you do and damned if you donât. But certainly we want to endure that progress can be made without losing the will to contribute. Tim Sent from my iPhone > On 4 Nov 2018, at 22:35, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Just to share my pain with you. Try to change something in the API of Commander? > I think that it will be nearly impossible. > Because Iceberg/Calypso depend on Commander and they are all managed > in different repositories. > So it means > - fork each > - probably introduce automatic deprecation > - do a PR for each of the subprojects (it means identify for each one > if we should work on dev or master and being able to checkout > the correct version which is not always possible) > - then waits.....that may be each of the PR got integrated > - now you lost total focus > - if one day you recover what you were doing then and only then you > may finish your change. > > Good luck. > > So to me the message is clear: stay away. > And this is what I'm doing. > We are damaging our agility on the altar of a pseudo modularity. > > So this is why I will focus on my tiny, uninteresting side projects. > Stef >> On Sun, Nov 4, 2018 at 3:14 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi Sven >> >> I agree with you. Ideally we would like to have much better tooling >> and process. >> Now the last time we discussed with Guille and Pablo about it: they >> estimated that this is over one year of work. >> And right now we do not have this engineering time to invest on this >> because other fronts need to be addressed. >> Still this is really slowing us. This is simple: I stopped thinking to >> improve something that touches external packages. >> So I will not work on the trivial changes that would improve Calypso/Iceberg. >> Why? Because this is tedious, boring, not rewarding. >> So yes we can do easily with iceberg simple fix on not external >> packages but as soon as >> - you need to load latest dev version (which can be a different one >> than the current one) >> - update your repo >> - fix >> - do a PR >> - .... wait for its integration >> >> So at the end we as a community can ask ourselves what is the reward >> model for such shitty work? >> And also what are we ready to give so that Pharo maintainers do such boring job. >> >> Right now without really doing it consciously I see myself doing >> either stupid fix or working on side projects >> and this is not a good long term approach because the core of Pharo >> needs a lot of work. >> >> Stef >>> On Fri, Nov 2, 2018 at 12:24 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>> >>>> On 2 Nov 2018, at 12:01, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> 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??? >>> >>> It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers. >>> >>> I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos. >>> >>> I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions. >>> >>>> 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. 4, 2018

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

by Sven Van Caekenberghe

> On 31 Oct 2018, at 20:58, David T. Lewis <lewis(a)mail.msen.com> wrote: > > This is very clear and well written. Thx. > 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 >> >> >> >> >> > > >

Nov. 4, 2018

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

by Stephane Ducasse

Just to share my pain with you. Try to change something in the API of Commander? I think that it will be nearly impossible. Because Iceberg/Calypso depend on Commander and they are all managed in different repositories. So it means - fork each - probably introduce automatic deprecation - do a PR for each of the subprojects (it means identify for each one if we should work on dev or master and being able to checkout the correct version which is not always possible) - then waits.....that may be each of the PR got integrated - now you lost total focus - if one day you recover what you were doing then and only then you may finish your change. Good luck. So to me the message is clear: stay away. And this is what I'm doing. We are damaging our agility on the altar of a pseudo modularity. So this is why I will focus on my tiny, uninteresting side projects. Stef On Sun, Nov 4, 2018 at 3:14 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi Sven > > I agree with you. Ideally we would like to have much better tooling > and process. > Now the last time we discussed with Guille and Pablo about it: they > estimated that this is over one year of work. > And right now we do not have this engineering time to invest on this > because other fronts need to be addressed. > Still this is really slowing us. This is simple: I stopped thinking to > improve something that touches external packages. > So I will not work on the trivial changes that would improve Calypso/Iceberg. > Why? Because this is tedious, boring, not rewarding. > So yes we can do easily with iceberg simple fix on not external > packages but as soon as > - you need to load latest dev version (which can be a different one > than the current one) > - update your repo > - fix > - do a PR > - .... wait for its integration > > So at the end we as a community can ask ourselves what is the reward > model for such shitty work? > And also what are we ready to give so that Pharo maintainers do such boring job. > > Right now without really doing it consciously I see myself doing > either stupid fix or working on side projects > and this is not a good long term approach because the core of Pharo > needs a lot of work. > > Stef > On Fri, Nov 2, 2018 at 12:24 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > > > > On 2 Nov 2018, at 12:01, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > > 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??? > > > > It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers. > > > > I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos. > > > > I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions. > > > > > 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. 4, 2018

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

by Stephane Ducasse

Hi Sven I agree with you. Ideally we would like to have much better tooling and process. Now the last time we discussed with Guille and Pablo about it: they estimated that this is over one year of work. And right now we do not have this engineering time to invest on this because other fronts need to be addressed. Still this is really slowing us. This is simple: I stopped thinking to improve something that touches external packages. So I will not work on the trivial changes that would improve Calypso/Iceberg. Why? Because this is tedious, boring, not rewarding. So yes we can do easily with iceberg simple fix on not external packages but as soon as - you need to load latest dev version (which can be a different one than the current one) - update your repo - fix - do a PR - .... wait for its integration So at the end we as a community can ask ourselves what is the reward model for such shitty work? And also what are we ready to give so that Pharo maintainers do such boring job. Right now without really doing it consciously I see myself doing either stupid fix or working on side projects and this is not a good long term approach because the core of Pharo needs a lot of work. Stef On Fri, Nov 2, 2018 at 12:24 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 2 Nov 2018, at 12:01, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > 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??? > > It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers. > > I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos. > > I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions. > > > 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. 4, 2018

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

by Stephane Ducasse

Hi norbert I'm not offended and we can talk. I'm just saying that OUR reality is a lot more complex that managing a separate project. Just today I stopped fixing things in Pharo (Smalltalk ui icons everywhere) just because this is a pain to fix several subprojects. Net result: no improvement. Stef On Fri, Nov 2, 2018 at 12:02 PM Norbert Hartl <norbert(a)hartl.name> wrote: > > 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. 4, 2018

FFI interfacing to thin C layers over C++ libraries [was Re: [squeak-dev] Squeak and Tesseract]

by Ben Coman

While I've done a lot of C programming that is useful for FFI interfacing, I've not done much C++. So just sharing something new I learnt today to help with FFI interfacing to combined C/C++ libraries. I thought maybe others in the same boat could be interested in this. [Original question asked in squeak-dev, cross-posting to pharo-dev] On Fri, 2 Nov 2018 at 21:06, Ben Coman <btc(a)openinworld.com> wrote: > > On Fri, 2 Nov 2018 at 18:44, Edwin Ancaer <eancaer(a)gmail.com> wrote: > >> As I'm looking at a way to automate the search of documents in my humble >> administration, I read some articles about OCR. I came along an article >> about using Python with Tesseract, to transform an scan of a document into >> text, that is searchable. >> >> My question now is if I can do something similar with Squeak. To my >> inexperienced eye, it seems like I should use FFI to call the functions in >> the Tesseract API, but this API is in C++, and I don't know if it is >> possible to use FFI to call C++ functions? >> > > You are right C++ is difficult because of the name mangling of function > symbols, > but good fortune I notice Tesseract has C bindings... > https://github.com/tesseract-ocr/tesseract#for-developers > https://github.com/tesseract-ocr/tesseract/blob/master/src/api/capi.h > so it looks like you are in the clear. > Browsing a deeper I got quite confused for a while. I could see a typedef definition for TessResultRenderer here... https://github.com/tesseract-ocr/tesseract/blob/master/src/api/capi.h#L83 "typedef struct TessResultRenderer TessResultRenderer" which I understood to must refer to *existing* struct, but I couldn't find the definition of that struct anywhere. In particular... $ git clone git@github.com:tesseract-ocr/tesseract.git $ cd tesseract $ find . -type f -name "*h" -exec grep -Hn TessResultRenderer {} \; but didn't find any struct definitions. I could only find TessResultRenderer as a class definition... https://github.com/tesseract-ocr/tesseract/blob/master/src/api/renderer.h#L… and the only thing that I guessed could possibly make sense was that C++ classes and structs could be used interchangeably. My google-fu failed to find anything useful, so an experiment... $ vi test.cpp #include <stdio.h> class SomeClass { public: int a; int b; }; typedef struct SomeClass SomeTypeDef; int main() { SomeTypeDef x; x.a = 5; x.b = 7; printf("Answer is %d\n", x.a + x.b); } $ gcc test.cpp $ ./a.out Answer is 12 Now I noticed that the TessResultRenderer member variables were private... https://github.com/tesseract-ocr/tesseract/blob/master/src/api/renderer.h#L… and curious about that I changed my test example from public to private which somewhat expectedly produced compile errors. So those TessResultRenderer member variables must only be accessed from a member function, but how is that C++ member function called from C to operate on a particular object? An example is TessResultRendererInsert... C Declaration: https://github.com/tesseract-ocr/tesseract/blob/c375f4fbf73b8f761b2e65e0e3a… C Definition: https://github.com/tesseract-ocr/tesseract/blob/c375f4fbf73b8f761b2e65e0e3a… C++ Declaration: https://github.com/tesseract-ocr/tesseract/blob/master/src/api/renderer.h#L… C++ Definition: https://github.com/tesseract-ocr/tesseract/blob/master/src/api/renderer.cpp… So in the C Defintion "the C++ member-function insert() as being called via a function pointer in the struct." (is that a reasonable way to describe it?) In this case, because of the private member variables, our FFI would treat TessResultRenderer as an opaque object, which simplifies things. I would guess in-Image direct access to the member variables from would need to account for the offset due to variables holding the function pointer to the member functions. cheers -ben P.S. for Tesseract FFI it might be good to start with reproducing this example... https://github.com/tesseract-ocr/tesseract/wiki/APIExample#example-using-th…

Nov. 4, 2018

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

by Shaping

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> 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 > > > > >

Nov. 3, 2018

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

by Sean P. DeNigris

Nicolas Cellier wrote > If killer feature is not the social part, then we don't really need > github. > Git, MC, or any other distributed VCS already handle the trivial ability > to > fork. Okay, fine ha ha, the social part is *the* killer advantage. Perhaps I should've inserted "committing" before "workflow". As to the triviality, IMHO it doesn't get much simpler than clicking "Fork" and then "Create PR", and I don't know of anything nearly that simple in the mcz world. Maybe per-project inboxes might have helped a bit, but always more to do than resources. Nicolas Cellier wrote > IMO, time spent to convince that a change must be merged back is not lost > time. Sure, but the key now is that you can do all that convincing *after* you continue with your own work, instead of being stalled. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 3, 2018

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

by Nicolas Cellier

So the killer feature is not the possibility to report issues, propose and link corrections, enhancements and new features to be merged back, have them automatically tested on continuous integration bots, comment code online and have discussions about implementation correctness or style... If killer feature is not the social part, then we don't really need github. Git, MC, or any other distributed VCS already handle the trivial ability to fork. Forking is very important for handling concurrent timelines. But a good fork is a fork that is merged back, because it preserves retro contributions. If divergence of interest is too high, then yes, the ability to definitely fork is important, but it should be last resort decision. IMO, time spent to convince that a change must be merged back is not lost time. Unless the change is not that good. A fork is a super easy and convenient way to handle the case in short term. But long term divergences soon become unsustainable drag. So please, be social and cooperative and favor win-win strategies :) Le 3 nov. 2018 03:25, "Sean P. DeNigris" <sean(a)clipperadams.com> a Ã©crit : NorbertHartl wrote > In order to make myself independent I fork the projects I consider > unstable and use the fork in our product. This way I have control when > there is something updated. This could also be a good way for pharo. I was thinking the same. This is also what I do. My goal is *never* to depend on external projects, only my forks. With GH this is trivial. With mcz repos it was much harder IMHO. And it seems to address Steph's valid concern because you just commit to your fork and keep moving ahead - no waiting, just create a PR and it's up to the maintainer to accept or not. BTW This concept of forking and insulating oneself from unstable external projects IMHO is *the* killer feature of GH for Smalltalk/Pharo workflows. How many hours I wasted trying to contact "maintainers" of abandonware mcz repos to integrate a fix! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 3, 2018

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

by Sean P. DeNigris

NorbertHartl wrote > In order to make myself independent I fork the projects I consider > unstable and use the fork in our product. This way I have control when > there is something updated. This could also be a good way for pharo. I was thinking the same. This is also what I do. My goal is *never* to depend on external projects, only my forks. With GH this is trivial. With mcz repos it was much harder IMHO. And it seems to address Steph's valid concern because you just commit to your fork and keep moving ahead - no waiting, just create a PR and it's up to the maintainer to accept or not. BTW This concept of forking and insulating oneself from unstable external projects IMHO is *the* killer feature of GH for Smalltalk/Pharo workflows. How many hours I wasted trying to contact "maintainers" of abandonware mcz repos to integrate a fix! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 3, 2018

[squeakland] strategies and tools for a comeback of Smalltalk using Scratch as entrance

by Bernhard HÃ¶fner

Hello Stephane and Jecel, thank your for your welcome. Before I start to explain my thought and ideas I want want to write short about my background. I work with ST80 since 1990. After a computer kid career since mid 1970th with Basic, Machine language, Assembler, FORTH and Pascal I ended up with Smalltalk 80 and I am always again fascinated about what happens with me and the subject that I am going to implement. ST80 structures the work and in an almost philosophical way it makes me learning more about the subject and its internal structure. I want to let you know that I am not a Smalltalk specialist. I had some bigger private projects but never worked with it on a professional base or in a team. Since about 10 years I had only flying visits to VisualWorks due to other priorities and have a view to Smalltalk more on "secondary literatureâ and so my view is more a view from outside. But ST80 never let me go. My main occupation did not end in an IT-job but in a âdown-homeâ business. As an electrical engineer I am working as technical consultant in the renewable energy sector. Thats why I know very good the âreal worldâ. On the other hand I am very interested in childhood and the process of learning (most of my relatives are kindergarden teacher). My experiences in both sectors satisfied me that people love continuity in the tools they are using. Continuity is meant in its mathematical meaning and describes that people doesn't like tools where they have ruptures in their learning curve. This applies especially to software tools. I think that this is the reason, why for example there are EXCELians who like to make everything in MS-EXCEL including writing letters and reports and WORDists, who do the same but everything in MS-WORD. I am convinced that people like continuous learning curves: small steps in learning result in small steps increasing efficiency or quality of result. There is another approach: Despite of my finding that ST80 is the most excellent language I witnessed a vanish of the language in the public perception since the 1990th. Yoshiki Ohshima spoke about the âsecrete weaponâ phenomenon of Smalltalk (compare similar effect on Lisp, described in this article: http://www.paulgraham.com/avg.html <http://www.paulgraham.com/avg.html> ), but I think this phenomenon leads in a generation of students growing up with not optimal tools because no one shows them ST80 in an enthusiastic way. I like to have whistle-blowers to tell them the secret. The digital world should be based on and maintained with the best tools. I know enough creepy software from my main occupation... For a comeback of ST80 I think it is essential to win the youth and hold the students. Otherwise the same happens as in many church parish or in clubs: once they loose one generation, the parish or club life dies. I write such elaborate because I want to let you understand why I like to see Scratch as the start phase of an software development environment / framework with Smalltalk 80 at its final phase. Friends of mine left Scratch because they missed such a "high endâ and they moved to very other programming languages. Maybe such a complete environment could lead in a tool Alan Kay dreamed about with its Dynabook idea. Scratch would be still an excellent starting point of such an environment. It is widespread in the young programmer scene, not only with LEGO, but also with KOSMOS, the leading producer of experimentation boxes in Germany. The German popular children TV-program âDie Sendung mit der Mausâ started recently a programming course with Scratch 3: https://programmieren.wdrmaus.de <https://programmieren.wdrmaus.de/>. Microsofts follows also the idea of a continuous language with his excellent looking tool MakeCode, that have links to popular games like MINECRAFT (see: "Chickens! - MakeCode for Minecraft Code Builderâ (https://www.youtube.com/watch?v=bDaOISL9_UE <https://www.youtube.com/watch?v=bDaOISL9_UE>), adaptors to micro controller boards (see: "https://makecode.microbit.org <https://makecode.microbit.org/>â - access is very low-thereshold: with one click you can start. - no registration or other stuff is needed) and a link from block view to a higher level programming language view ( https://makezine.com/2017/09/20/learn-basics-javascript-makecode/ <https://makezine.com/2017/09/20/learn-basics-javascript-makecode/> - very nice with flying help for blocks including JavaScript code ). Unfortunately it ends up in JavaScript and not in ST80. I think it would be better to come from block programming languages direct to ST80 - I know several people coming from imperative languages and were not able to adapt to the object oriented approach. The world is object oriented like robots, sensors, actors! Maybe the pure object orientation of ST80 would be the weapon to beat MakeCode. John Maloney and Yoshiki Ohshima gave me very worthy hints to Scratch based branches that realize most of my wishes: Microcontroller access: http://microblocks.fun <http://microblocks.fun/> Sqeak based Ipad-implementation with access to Ipad-Sensors etc: https://en.scratch-wiki.info/wiki/Pyonkee <https://en.scratch-wiki.info/wiki/Pyonkee> Scratch with connection to ST80: http://www.phratch.com <http://www.phratch.com/> Scratch branch âGPâ, with the idea that it is better teaching experts a useful programming language to have them writing themselves applications they need for their work instead of having software developers learning the experts subjects to write software for the experts: http://gpblocks.org <http://gpblocks.org/> All that is fascinating and promising but I am afraid about the barrier of this "marketplace of possibilitiesâ for children to find the optimal track. My wish would be a cooperation of the creators of these excellent tools to bring the properties together, leading in one transparent programming tool. Maybe with modules which can be loaded and unloaded but with a clear and redundancy free structure and user interface. There is much more to say, but the email is long enough now. What do you think about this idea. Best Regards, Bernhard > Am 26.10.2018 um 22:27 schrieb Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>>: > > Hi Bernhard > > we are interested in that topics. This is why I wrote the botsinc book > in the past and more recently learning OOP with TDD in Pharo book. > Now I do not have much resources for the topic. > Stef > On Fri, Oct 26, 2018 at 2:16 PM Bernhard HÃ¶fner <bernhard.hoefner(a)gmx.de <mailto:bernhard.hoefner@gmx.de>> wrote: >> >>> Hello Group. I like to discuss about the subject and have also some ideas. But I want to ask first for the proper list within the forum. I heard that there is a discussion ongoing and want to participate. >>> >>> I will send this question to Squeak and Pharo usegroup and to the Phratch-developer. I assume that there is a common discussion about the subject. Hopefully there is no need to open on each platform an individual thread. >>> >>> Regards, Bernhard >> >

Nov. 2, 2018

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

by Norbert Hartl

> Am 02.11.2018 um 12:23 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> On 2 Nov 2018, at 12:01, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> 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??? > > It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers. > It seems Iâm not very clear when writing mails. I understand why this happens and I understand it needs to be that way because of less annoyance and improved speed. I donât understand how it is done explicitly. As we have a process that builds the image where are those changes applied? Is there a copy of the original package that gets tweaked? > I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos. > Yes, Iâm getting used to git although I donât like it. One reason I took several days time to help migrate projects from smalltalkhub to github is exactly this. In order to make myself independent I fork the projects I consider unstable and use the fork in our product. This way I have control when there is something updated. This could also be a good way for pharo. If there is a github project where every external project is forked to and used in pharo. This way you can control upstream and you can add tweaks that are needed for a release. Iâm intrigued which approaches people do for what reasons. > I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions. > Agreed. Norbert >> 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 Sven Van Caekenberghe

> On 2 Nov 2018, at 12:01, Norbert Hartl <norbert(a)hartl.name> wrote: > > 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??? It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers. I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos. I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions. > 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 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

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