On 9 April 2018 at 14:50, Thierry Goubier <thierry.goub...@gmail.com> wrote:

> 2018-04-09 2:18 GMT+02:00 Esteban A. Maringolo <emaring...@gmail.com>:
> > Even if he is a troll, he pointed out many things that aren't given
> > priority because we're building "next great stuff" and with the limited
> > resource you either stop to world to fix what's already made or you move
> > forward.
> >
> > And IMO it is true that the next great stuff is being built, a better
> > paradigm, moldability, and whatnot, but that means that, for a while,
> > tools, and the image itself won't be "rock solid", and since most things
> > are not backportable or maintained (there are no resources to have LTS
> > versions), it is hard to define what's the minimum rock-solid core on
> > which to build upon.
>
> I wonder if some things could be solved by taking a slightly different
> path...
>
> - Non rock solid base could be cared for by debugging that allways work
>
> - Not threaded image could be solved by "image sharing between processes"
>

Can you expand on this. I can't follow.


>
> - Multiple host windows would mean forking the image
>

I presume your mean native fork(), rather than Smalltalk #fork.

cheers -ben


>
> Imagine a world where:
> - The smalltalk debugger can remote debug via gdb(*) a locked image
> (or one where you have crashed the world because you played with core
> graphics stuff)...
> - The smalltalk debugger can inject new code into a remote image via
> gdb again (**).
> - Two images can easily share objects with almost zero overhead(***)
> - One image can easily keeps its code in sync with another one (object
> duplication between images)
>
> I know of TelePharo, and, after looking at the underlying
> implementation, it's not good enough. The core undebuggability of the
> platform is not solved (at all).
>
> The undebuggability of the platform is a significant barrier. I worked
> on the SmaCC GT debugger because my students were regularly locking
> their images with it (usually something as simple as stepping over the
> end of the computation) so I've added many, many guards, to try to
> protect from that; I know think a strong limitation of exploring new
> debug modes is mainly linked to the ease of locking your image with
> it.
>
> Regards,
>
> Thierry
>
> (*) gdb over serial talking to a boot eeprom equivalent, mapped with a
> remapping of step to smalltalk instructions (like in a true debugger)
> (**) So that, from that smalltalk over gdb debugger, you can fix,
> compile and proceed
> (***) And so, no story of running a "determine the right object graph
> with more smalltalk code... ", that is too slow
>
> > E.g. The infinite walkback error pointed in this screenshot
> > https://i.imgur.com/7jiKIhd.png still chases me from time to time, and I
> > remember having reported it a long time ago, and it was considered fixed.
> >
> > So I wouldn't feed the troll, but I woudln't kill the messenger either.
> >
> > Regards,
> >
> >
> > On 07/04/2018 14:26, Dimitris Chloupis wrote:
> >> yeah the guy (martin whatever) is a troll, if I remember correctly its
> >> the same dude we had on the reddit forum for Smalltalk that has been
> >> attacking Pharo with pure lies. He is a typical troll that blows off
> >> steam by annoying other people. I am with Stef with this one, the only
> >> way to win against a troll is silence. I had a very recent experience
> >> where the person in charge underestimated a troll, he overflown the
> >> mailing list with negative, many people took the bait and tried to have
> >> a civilized discussions with him, he drag it one for month until people
> >> started abandoning the community and the community essentially died.
> >>
> >> I adviced them not to feed the troll but as in many other cases, people
> >> dont even listen.
> >>
> >> Pharo is far from perfect, but this is not a logical discussion , its
> >> pure troll tactic. Do not underestimate the power of a troll, it is more
> >> powerful than you can imagine and feed on politeness and rationality.
> >>
> >> Don't feed the troll.
> >>
> >> On Sat, Apr 7, 2018 at 8:13 PM p...@highoctane.be
> >> <mailto:p...@highoctane.be> <p...@highoctane.be
> >> <mailto:p...@highoctane.be>> wrote:
> >>
> >>     interruptible.. yes!
> >>
> >>     On Sat, Apr 7, 2018, 19:10 Thierry Goubier
> >>     <thierry.goub...@gmail.com <mailto:thierry.goub...@gmail.com>>
> wrote:
> >>
> >>         Hi Alex,
> >>
> >>         Le 07/04/2018 à 17:48, Aliaksei Syrel a écrit :
> >>         > Hi
> >>         >
> >>         > Here is a link to a report about their experience with Pharo:
> >>         > https://gitlab.fit.cvut.cz/taibrmar/sokoban-using-bloc
> >>         >
> >>         > There definitely exist things that should be improved. It is a
> >>         pity when
> >>         > tiny “minor” issues leave such an unpleasant aftertaste.
> >>
> >>         Some of them are, sadly, quite unacceptable, IMHO.
> >>
> >>         I would really dream of a stable, correctly interruptible (i.e.
> >>         a Cmd-.
> >>         that really works), limited Pharo core. That would help
> >>         development so
> >>         significantly and allow more experiments.
> >>
> >>         I solve that by making stuff that distance itself as much as
> >>         possible
> >>         from a lot of the Pharo stuff that evolves far too much, far too
> >>         fast to
> >>         be relied upon (widgets, graphics, editors), and I'm looking
> >>         forward to
> >>         building a limited(*) image with just and only the things I
> rely on.
> >>
> >>         One of the thing I need is a CI that triggers both on my code
> >>         releases
> >>         and any Pharo update (including the stable ones) since even
> stable
> >>         releases may change core APIs.
> >>
> >>         > Anyway, there are lovers and haters of every language.
> >>
> >>         That I can agree with :)
> >>
> >>         > Some people even
> >>         > give dislikes to videos on YouTube that show how veterinarians
> >>         heal cats...
> >>         >
> >>         > All the best
> >>         > Alex
> >>
> >>         Regards,
> >>
> >>         Thierry
> >>
> >>         (*) I did try with the minimal image, and the tools are clearly
> >>         limiting.
> >>
> >>         > On Sat, 7 Apr 2018 at 17:27, Stephane Ducasse
> >>         <stepharo.s...@gmail.com <mailto:stepharo.s...@gmail.com>
> >>         > <mailto:stepharo.s...@gmail.com
> >>         <mailto:stepharo.s...@gmail.com>>> wrote:
> >>         >
> >>         >     I tend to not care about people pissing on me via a
> >>         pseudo. This is
> >>         >     too easy and too microscopic to have any value.
> >>         >     Thanks Philippe, Luke and Ben because you use your real
> names.
> >>         >
> >>         >     On Thu, Apr 5, 2018 at 2:07 PM, Esteban Lorenzano
> >>         >     <esteba...@gmail.com <mailto:esteba...@gmail.com>
> >>         <mailto:esteba...@gmail.com <mailto:esteba...@gmail.com>>>
> wrote:
> >>         >      > Hi,
> >>         >      >
> >>         >      > yesterday someone posted an article on HN about the
> >>         Pharo MOOC
> >>         >     and there has
> >>         >      > been some negative posts there.
> >>         >      > I would like to call people who can have the time to
> >>         answer there
> >>         >     and help
> >>         >      > to explain better and also contribute to contest that
> FUD
> >>         >     someones (we know
> >>         >      > who they are… sames as always) are spreading.
> >>         >      >
> >>         >      > here the link :
> >>         https://news.ycombinator.com/item?id=16754872
> >>         >      >
> >>         >      > (this is not loosing time, people searching for Pharo
> >>         will likely
> >>         >     see this
> >>         >      > kind of messages… at least we need to offer our point
> >>         of view)
> >>         >      >
> >>         >      > cheers!
> >>         >      > Esteban
> >>         >
> >>         > --
> >>         > Cheers,
> >>         > Alex
> >>
> >>
> >
> > --
> > Esteban A. Maringolo
> >
>
>

Reply via email to