- Pharo-dev - lists.pharo.org

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