- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] vm crash when using rairedTo: with fractions

by Stephane Ducasse

I like your answer nicolas. If this is really important for any business or any dev around let us know we can just tag it and we will port it for 6.2. Stef On Mon, Aug 14, 2017 at 11:29 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi Tim, > I'd say: is this a showstopper? > How often do you raise a Fraction to the power of another Fraction with > large denominator (> 10000)? > Or is it used indirectly by some kind of Framework? > > If yes then open a pharo bug entry and mark for 6.x, else just wait 7.x... > > Nicolas > > > 2017-08-14 10:49 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >> >> Is there a way for this to get back into 6.1 - so we can shoot for a >> stable 6.x version that will last us for a year while 7.x is under >> development? >> >> Iâm not familiar with how point release are handled in Pharo, and I get >> the impression that this is going to be a slightly rockier year as there >> have been some pretty revolutionary changes made to get us here. >> >> As its a vm change does this mean we get 6.2 queued up somehow? >> >> Tim >> >> > On 13 Aug 2017, at 20:12, Stephane Ducasse <stepharo.self(a)gmail.com> >> > wrote: >> > >> > Tx eliot. >> > >> > >> > On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda >> > <eliot.miranda(a)gmail.com> wrote: >> >> Hi Andrei, >> >> >> >> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis >> >> <chisvasileandrei(a)gmail.com> >> >> wrote: >> >>> >> >>> >> >>> Hi, >> >>> >> >>> I was executing this code '(2009/2000) ** (3958333/100000)' with the >> >>> Pharo6.1 distribution and the vm crashed with she stack attached >> >>> below. >> >>> Tried it on both mac and windows 10. >> >>> Seems that #raisedTo: has a special case for fractions that ends up >> >>> calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash. >> >> >> >> >> >> The plugin is now fixed; see VMMaker.oscog-eem.2262. I'll generate >> >> code >> >> soon (am debugging something you're familiar with that takes several >> >> hours >> >> to run and don't want to generate sources while it's running). But I'm >> >> glad >> >> you've found a better way! This case creates 600k byte large integers >> >> and >> >> takes forever to run :-) >> >> >> >>> >> >>> Cheers, >> >>> Andrei >> >>> >> >>> >> >>> 0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) >> >>> LargePositiveInteger >> >>> 0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) >> >>> LargePositiveInteger >> >>> 0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) >> >>> LargePositiveInteger >> >>> 0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) >> >>> LargePositiveInteger >> >>> 0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: >> >>> a(n) LargePositiveInteger >> >>> 0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: >> >>> a(n) >> >>> LargePositiveInteger >> >>> 0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009 >> >>> 0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction >> >>> 0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction >> >>> 0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction >> >>> 0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject >> >>> 0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler >> >>> 0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) >> >>> RubSmalltalkEditor >> >>> 0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) >> >>> RubSmalltalkEditor >> >>> 0xade0b8 M >> >>> GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint >> >>> 0x3062fdc8: a(n) GLMMorphicPharoScri >> >>> enderer >> >>> 0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) >> >>> MorphicAlarm >> >>> 0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm >> >>> 0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState >> >>> 0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) >> >>> WorldState >> >>> 0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState >> >>> 0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph >> >>> 0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState >> >>> 0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState >> >>> 0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph >> >>> 0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph >> >>> class >> >>> 0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) >> >>> MorphicUIManager >> >>> 0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure >> >>> >> >> >> >> >> >> >> >> -- >> >> _,,,^..^,,,_ >> >> best, Eliot >> > >> >> >

Aug. 14, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Guillermo Polito

Hi Eliot, On Mon, Aug 14, 2017 at 9:07 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Guille, > > On Mon, Aug 14, 2017 at 3:42 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi all, >> >> I'm proposing a kind-of critical change that I believe is very good for >> the health of the system: I want that the startup of the system runs in >> maximum priority and becomes non-interruptable. >> >> Right now, when you save your image, the shutdown and startup are run in >> the same priority than the process that triggered the save (usually the ui >> or the command line, priority 40). This can cause lots of problems and race >> conditions: processes with higher priorities can interrupt the >> shutdown/startup and try to do something while the system is unstable. As a >> side effect also, when you use extensively the command line, you start >> stacking startup contexts from old sessions: >> >> ... >> session 3 ctxt 4 <- This guy makes a save and a new session starts >> session 3 ctxt 3 >> session 3 ctxt 2 >> session 3 ctxt 1 >> session 2 ctxt 4 <- This guy makes a save and a new session starts >> session 2 ctxt 3 >> session 2 ctxt 2 >> session 2 ctxt 1 >> session 1 ctxt 4 <- This guy makes a save and a new session starts >> session 1 ctxt 3 >> session 1 ctxt 2 >> session 1 ctxt 1 >> >> Old contexts are never collected, and the objects they referenced neither. >> >> To fix these two problems I propose to do every image save/session start >> in a new process in maximum priority. That way, other process should not be >> able to interrupt the startup process. Moreover, every session >> shutdown/startup should happen in a new clean process, to avoid the session >> stacking. >> > > I think you're mixing up two things here. One is wanting to make > startup/shutdown uninterruptible by raising the priority of the process > that does startup & shutdown. The other is starting the system with a new > process. > Yes, we agree they are two different issues. > > I don't want to express an opinion on the former, but I think the latter > is not a good idea. One important feature of Smalltalks up until your > proposed change is that snapshotAs:thenQuit: can be sent anywhere, causes a > snapshot and resumes execution after the send of snapshotAs:thenQuit: once > the internals of snapshotAs:thenQuit: have rebooted the system. This is > really useful: > > - applications can snapshot the system as they choose for checkpointing, > etc > - for VM debugging one can execute the snapshotAs:thenQuit: anywhere (for > example inside an inspector where self is bound to some interesting object) > and follow it by whatever code one chooses, e.g. to provoked a bug. For > example > Smalltalk snapshotAs: 'foo' thenQuit: true. > self doSomethingTerminal > > Your change will break this and make it much harder to debug certain > things. > But this behaviour is kept in my proposal :). Actually, what I propose is mainly changing the following: SessionManager >> #snapshot: save andQuit: shouldQuit -> renamed into #launchSnapshot: save andQuit: quit. and then define: snapshot: save andQuit: quit | isImageStarting wait | wait := Semaphore new. [ isImageStarting := self launchSnapshot: save andQuit: quit. wait signal ] forkAt: Processor highestPriority. wait wait. ^ isImageStarting Since the snapshot runs in max priority, users will be suspended until the startup is run in a safe manner. Moreover, I added a semaphore to handle the case where a process in max priority calls a snapshot. To me this proposal is cleaner than changing the priority of the current thread to the top priority, to then reset it to the old priority. > One will be able to use the file-in scheme, but this implies the system > will always run the compiler first, and one may not want that. > I did not get this one. Could you explain further? If you mean calling the command line handlers to install .st files for example, the command line handlers are called before anything else today in any case, as they are subscribed to the startup. So even if you saved your image from the world menu, the saved image will try to handle command line arguments on the next startup. > Further, the system stacking looks like a bug that should be addressed > elsewhere. Isn't it session management's responsibility for dropping older > sessions? > Yes, it's a different issue, I know. The current issue is that there is code that creates a snapshot as part of the startup. Starting up from a separate process is part of the solution for this (as a way to prevent it, whatever the users do). Thanks for looking into it :) Guille

Aug. 14, 2017

Re: [Pharo-dev] PharoJS crashes at first try

by Stephane Ducasse

On Sun, Aug 13, 2017 at 9:19 PM, Frank-B <frank.berger.software(a)web.de> wrote: > Stephane, > > thank you for your open words. > > 1) No I am NOT Frank Lesser and I will communicate this even clearer in a > personal email to you. Ok ;) > > 2) I had tried to make very clear that I see the Pharo project very positive > and my critics as being (at least intended) constructive. Ok :) > 3) I never care about my reputation. I only care about truth, facts and a > sincere appearance. Few people appreciate this attitude and I do not value > the others all too high or seriously. Unfortunately, we all have to live in > these timees of universal lies, deception and fraud. You probably know the > good German word "LÃ¼genpresse" and my version is: "the current Zeitgeist > equals LÃ¼genpresse". I do not german and the underlying message. My advice is that generally people are nice and willing to help but it depends also how people behave :). > 4) I have some good, solid and unusual ideas how I could improve the Pharo > project considerably but for several reasons it is much to early to discuss > this. It will take another 2-3 years and I will definitely come back when > the time has come on my side. > > 5) As a contributor in the general Pharo sense I am currently neither > capable (working 85-100 hours a week on my projects) nor eligible and the > latter reason is not simple to explain, so I leave it at that for now. Ok. It is up to you. You see today I saw the method -> in Object and there is not a little example in the comments. So I will add one so that newbies like my sons can read and understand without their father telling them. And this is a contribution. :) Stef > > Frank > > > > > > -- > View this message in context: http://forum.world.st/PharoJS-crashes-at-first-try-tp4960686p4960770.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 14, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Eliot Miranda

Hi Guille, On Mon, Aug 14, 2017 at 3:42 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi all, > > I'm proposing a kind-of critical change that I believe is very good for > the health of the system: I want that the startup of the system runs in > maximum priority and becomes non-interruptable. > > Right now, when you save your image, the shutdown and startup are run in > the same priority than the process that triggered the save (usually the ui > or the command line, priority 40). This can cause lots of problems and race > conditions: processes with higher priorities can interrupt the > shutdown/startup and try to do something while the system is unstable. As a > side effect also, when you use extensively the command line, you start > stacking startup contexts from old sessions: > > ... > session 3 ctxt 4 <- This guy makes a save and a new session starts > session 3 ctxt 3 > session 3 ctxt 2 > session 3 ctxt 1 > session 2 ctxt 4 <- This guy makes a save and a new session starts > session 2 ctxt 3 > session 2 ctxt 2 > session 2 ctxt 1 > session 1 ctxt 4 <- This guy makes a save and a new session starts > session 1 ctxt 3 > session 1 ctxt 2 > session 1 ctxt 1 > > Old contexts are never collected, and the objects they referenced neither. > > To fix these two problems I propose to do every image save/session start > in a new process in maximum priority. That way, other process should not be > able to interrupt the startup process. Moreover, every session > shutdown/startup should happen in a new clean process, to avoid the session > stacking. > I think you're mixing up two things here. One is wanting to make startup/shutdown uninterruptible by raising the priority of the process that does startup & shutdown. The other is starting the system with a new process. I don't want to express an opinion on the former, but I think the latter is not a good idea. One important feature of Smalltalks up until your proposed change is that snapshotAs:thenQuit: can be sent anywhere, causes a snapshot and resumes execution after the send of snapshotAs:thenQuit: once the internals of snapshotAs:thenQuit: have rebooted the system. This is really useful: - applications can snapshot the system as they choose for checkpointing, etc - for VM debugging one can execute the snapshotAs:thenQuit: anywhere (for example inside an inspector where self is bound to some interesting object) and follow it by whatever code one chooses, e.g. to provoked a bug. For example Smalltalk snapshotAs: 'foo' thenQuit: true. self doSomethingTerminal Your change will break this and make it much harder to debug certain things. One will be able to use the file-in scheme, but this implies the system will always run the compiler first, and one may not want that. Further, the system stacking looks like a bug that should be addressed elsewhere. Isn't it session management's responsibility for dropping older sessions? For normal users, this should have no side effect at all. This change will > have a good impact on people working on the debugger and the stack such as > fueling-out the stack because they will have a cleaner stack. > > There is however a side-effect/design point to consider: startup actions > should be quick to run. If a startup action requires to run a long-running > action such as starting a server or managing a command line action, that > should run in a separate process with lower priority (usually > userPriority). In other words, the startup action should create a new > process managing its action. > > If you want to review (and I'd be glad) > > Pull request: https://github.com/pharo-project/pharo/pull/198 > Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 > Current validation going on: https://ci.inria.fr/pharo-ci- > jenkins2/job/Test%20pending%20pull%20request%20and% > 20branch%20Pipeline/view/change-requests/job/PR-198/ > > Guille > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- _,,,^..^,,,_ best, Eliot

Aug. 14, 2017

Re: [Pharo-dev] Little article: keep your pharo repository in sync

by Stephane Ducasse

Thanks guille This is great to have all these ressources on git integration. Once you are done :) we can really easily create a booklet around git and pharo. Stef On Mon, Aug 14, 2017 at 7:40 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > This little article explains how you should keep your branches in sync > with iceberg or (in worst-case scenario) from the command line. > > https://github.com/guillep/PharoIntegrationProcess/wiki/ > Keep-your-repo-in-sync > > These are the things I do all the time, if you have other cases, or you > want to add anything, just tell. > > Guille > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Aug. 14, 2017

Re: [Pharo-dev] Fuel fails in squeak

by H. Hirzel

On 8/14/17, henry <henry(a)callistohouse.club> wrote: > I am slightly overwhelmed at > the fractious nature of repositories, between and within Squeak & Pharo, and > also encoder serializations. I hope for reconsolidation. > > - HH Objects from Pharo written by Fuel may be read back into a Pharo image. The same applies for a Squeak image. Objects from Squeak serialized with Fuel may read into another Squeak image. Fuel is a binary serializer http://wiki.squeak.org/squeak/6451 To move objects from Pharo to Squeak you need a text based solution such as SIXX http://wiki.squeak.org/squeak/84 or JSON. HTH HH

Aug. 14, 2017

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

by Jimmie Houchin

Thank Tim, My primary reason to submit the message was not to necessarily persuade you per se. But to provide something historical for the mailing list as this can be a recurring subject. Why use Pillar markup instead of ???(insert personal favorite). If Pharo were to decide on a different markup language. The question would still be which one, why and then how do we proceed. Then our extensions may not be accepted by the greater body of users of said markup. We would still be contributing to the fragmentation of markup. As far as familiarity, I don't know. And familiarity with what. I do not find that reStructuredText to be similar to Markdown. It would stop people from asking why we aren't using Markdown. But it wouldn't prevent others. Why aren't we using GFM Markdown, or Kramdown or Commonmark or ...? Why aren't we using YAML or reST or AsciiDoc or insert latest greatest creation markup or current flavor of the moment. Which is why I wanted to point out that there is no consensus among users of markup languages. At least I do not see one. Nor do I believe that we have seen the end of creation of new markup languages. I understand the difficulty, though I do not suffer from it as I have not mastered any of those other languages. I have been using Squeak/Pharo for a long time. I struggle when I look at those other languages. To me they are the foreign ones. And I do not see these emerging standards you refer to. When we see Python, Ruby, Perl, C++, various projects, etc. communities having consensus on a common markup for documentation. Then I see an emerging standard. Until then it seems to possibly be an emerging standard for a particular markup language which is among the set of markup languages. If we were the only language and development environment doing our own thing. Then we might have a very good reason to talk. But we are not. Python with its enormous community does its own thing. I don't know that other languages have a consensus for markup for documentation except for Python and Pharo. While writing this email I went and discovered that even GitHub is not dogmatic about the subject. Obviously they have an opinion. But they permit multiple markup languages. Quite possibly someone could write a Pillar tool for GitHub to use and then we could just submit Readme.pillar for our projects. :) https://github.com/github/markup Shows that GitHub allows for .markdown, .mdown, .mkdn, .md; .textile; .rdoc; .org; .creole; .mediawiki, .wiki; .rst; .asciidoc, .adoc, .asc; .pod. So it seems that there are many communities on GitHub who prefer their own markup and tools. We could possibly write the Pillar tool for GitHub or an exporter to the preferred markup language of the above. This author provides arguments for using reStructuredText over Markdown for GitHub documents. Citing deficiencies in Markdown and expressiveness in reST. https://gist.github.com/dupuy/1855764 So again. I am just not seeing a consensus around any emerging standard for "the markup language". At the same time if you are desirous of writing in Commonmark in your text editor. Can you not write conversion software that goes from Commonmark to Pillar? Thus, meeting want you want and what we require? If you were to do so, you would definitely have a good understanding of the differences in philosophy and capabilities of each. Just a thought. Any way, thanks for engaging in the conversation. I wasn't targeting you personally, but rather the topic. You are not alone in your thinking. The Pharo community is not alone in its thinking either. Thanks. Jimmie On 08/14/2017 11:34 AM, Tim Mackinnon wrote: > Jimmie et al. nicely reasoned arguments - and Doru's point about > controlling the syntax is an interesting one that I hadnât thought about. > > Personally, I find having too many similar syntaxâs confusing - > contributing to things is hard enough - having to remember that its !! > Instead of ## and ââ instead of ** is just frustrating for me. > > My vote would be what Peter suggested - use > http://spec.commonmark.org/0.28/ and put our Pillar extensions back on > top for things that Stef was mentioning. (I think thatâs what Iâve > understood gfm markdown is). > > Sure, maybe we were first with Pillar, but for me, lots of programming > is in other languages, and I use Smalltalk where I can, and a hybrid > of multiple languages and projects is often the reality - so a lowest > common denominator of Markdown is just easier. The fact that we are > quite close to what our colleagues in other languages use (regardless > of what Python has chosen), is quite interesting. > > That said, if the community wants to stick to its gunâs thats fine - I > will probably still investigate how to use Commonmark for myself, and > will still contribute to Pillar docs where I can (and curse history) - > but I think we are long better off trying to join emerging standards > where we can particularly if they arenât our core language thing. And > it just makes it less frictionless for ourselves and newcomers. > > Of course, if we were to move, we would need to translate a lot of > quality docs to a new format - but I would be up for contributing to > that if that was a deciding factor. > > Tim > > >> On 14 Aug 2017, at 16:41, Jimmie Houchin <jlhouchin(a)gmail.com >> <mailto:jlhouchin@gmail.com>> wrote: >> >> TL;DR >> >> Main points: >> Their is no universally accepted markup language. >> Other communities use their own markup and tools and their markup >> and tools choice is not determine by other communities decisions. >> We need a language and tool chain that we can control and maintain >> which accomplishes our goals. >> Our language and tools already exist and have existed for longer than >> most of the other markup languages. Of course they existed in various >> different forms over the years and have evolved into what they >> currently are. >> It might be nice to have a GFM Markdown exporter from Pillar for >> GitHub projects. >> >> >> I just want to comment on the fact that there is no universal markup >> language that every development community has settled upon. Making >> Markdown or some variant the markup language for Pharo only aligns us >> with a certain part of the development community. Even Markdown is >> not unified as is evident by the discussion. >> >> It is true that GitHub uses their variant of Markdown. And as long as >> we use GitHub we will need to use their variant for documents that >> reside on their system. >> >> However as a significant counter example to lets all use gfm >> Markdown, is the Python community and their documentation. >> >> https://docs.python.org/devguide/documenting.html >> """ >> 7. Documenting Python >> The Python language has a substantial body of documentation, much of >> it contributed by various authors. The markup used for the Python >> documentation is reStructuredText, developed by the docutils project, >> amended by custom directives and using a toolset named Sphinx to >> post-process the HTML output. >> >> This document describes the style guide for our documentation as well >> as the custom reStructuredText markup introduced by Sphinx to support >> Python documentation and how it should be used. >> >> The documentation in HTML, PDF or EPUB format is generated from text >> files written using the reStructuredText format and contained in the >> CPython Git repository. >> """ >> >> So the Python community uses their own markup language and their own >> tool chain. So therefore, it is not wrong for a community to go their >> own way, for their own reasons. Even within the conventional file >> based languages such as Python. >> >> The fact that you have tools such as Pandoc, suggest that there is >> not true uniformity or unanimity among developers as to the best >> markup language or tool chain. >> >> I believe that a language that we can control and maintain is better >> than adopting some other foreign markup language that is neither >> better, nor unanimously used by all. That would ultimately >> potentially require extensions to accomplish our goals. Then we would >> be maintaining someone else's language with our extensions that may >> or may not be accepted by the larger community. This does not prevent >> but rather encourages fragmentation of the existing Markdown. >> >> Regardless, Pillar markup already exists. The tools in Pharo already >> understand it. Should someone desire to use Pharo which is far more >> different from Python/Ruby/etc. than Pillar syntax is from Markdown. >> Then it should be worth their effort to learn our tools. >> >> Pillar markup is older than Markdown, etc. It's history begins in >> SmallWiki. It isn't as if we jumped up and decided to create >> something new in order to be different. Our markup and tools are >> older. They (and others) are the ones that decided to do their own >> markup and tools. And it is okay that they did so. Nothing wrong with >> doing so. Every community has the right to what they believe is best >> for their community. Even if other communities disagree. >> >> The ability to control and maintain is highly valuable. We can >> understand what our requirements are for today. But we can not know >> what the requirements are in the future. Nor can we know that >> Markdown or whomever will have such requirements when they appear. It >> is easy to see in the beginning with the Squeak Wiki syntax to the >> now Pillar syntax, changes that have been made to accommodate new >> requirements as they became known. We need to maintain that ability. >> Sure we would reserve the right to do so in any language we adopt. >> But the then current standard bearer of said language would determine >> whether what we do is acceptable and incorporate or whether we are >> then in fact adding to their fragmentation. Pillar is ours. There is >> not fragmentation when we evolve. >> >> However, since we have made a decision to use GitHub and GitHub has >> made a decision to use their own GFM Markdown. It might be nice to >> have a GFM Markdown exporter from Pillar for GitHub projects. This >> way we can use our own tools and markup language to accomplish >> whatever we want to accomplish. Including generating a Readme.md for >> our GitHub projects. >> >> Just wanted to toss out this simple opinion and facts about the >> situation. >> >> Jimmie >> >> >> On 08/14/2017 04:10 AM, Tudor Girba wrote: >>> Hi Tim, >>> >>> The main benefit of relying on Pillar is that we control its syntax >>> and can easily extend it for our purposes. Also, there was quite a >>> bit of engineering invested in it, and even though we still need to >>> improve it, there exists a pipeline that allows people to quickly >>> publish books. >>> >>> The figure embedding problem is one example of the need to customize >>> the syntax and behavior, but this extensibility will become even >>> more important for supporting the idea of moving the documentation >>> inside the image. For example, the ability to refer to a class, >>> method or other artifacts will be quite relevant soon especially >>> that the editor will be able to embed advanced elements inside the text. >>> >>> Cheers, >>> Doru >>> >>> >>>> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >>>> Hi Stef - I think yourâs is a fair requirement (in fact I hit >>>> something similar when doing a static website using a JS markdown >>>> framework - and this is why I mentioned Kramdown which adds a few >>>> extras to regular markdown - but it feels like it goes a bit too far). >>>> >>>> My next item on my learning todo list was to try and replace that >>>> JS generator with something from Smalltalk - so I think we can >>>> possibly come up with something that ticks all the right boxes (Iâd >>>> like to try anyway). >>>> >>>> Iâll keep working away on it and compare notes with you. I think >>>> with Pillar, it was more that things like headers, bold and italics >>>> are similar concepts but just use different characters - so I keep >>>> typing the wrong thing and getting frustrated particularly when we >>>> embrace Git and readme.md is in markdown. >>>> >>>> >>>> Tim >>>> >>>>> On 13 Aug 2017, at 20:08, Stephane Ducasse >>>>> <stepharo.self(a)gmail.com> wrote: >>>>> >>>>> Hi tim >>>>> >>>>> I personally do not care much about the syntax but I care about what I >>>>> can do with it >>>>> (ref, cite, ... ) >>>>> I cannot write books in markdown because reference to figures!!!!!! >>>>> were missing. >>>>> >>>>> And of course a parser because markdown is not really nice to parse >>>>> and I will not write a parser because I have something else to do. I >>>>> want to make pillar smaller, simpler, nicer. >>>>> >>>>> Now if someone come up with a parser that parse for REAL a markdown >>>>> that can be extended with decent behavior (figure reference, section >>>>> reference, cite) and can be extended because there are many things >>>>> that can be nice to have (for example I want to be able to write the >>>>> example below) and emit a PillarModel (AST) we can talk to have >>>>> another syntax for Pillar but not before. >>>>> >>>>> [[[test >>>>> 2+3 >>>>>>>> 5 >>>>> ]]] >>>>> >>>>> and being able to verify that the doc is in sync. >>>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim(a)testit.works> >>>>> wrote: >>>>>> Of course, I/we recognise and appreciate all the work that's gone >>>>>> into docs in pillar - but I think it should be reasonably >>>>>> straightforward to write a converter as it is pretty closely >>>>>> related from what I have seen. >>>>>> >>>>>> So I don't make the suggestion flippantly, and would want to help >>>>>> write a converter and get us to a common ground where we can >>>>>> differentiate on the aspects where we can excel. >>>>>> >>>>>> Tim >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>>>> >>>>>>> A long time issue with Markdown was that there was no >>>>>>> standardization (and when I used Pillar's MD export ~2 years ago >>>>>>> it didn't work well). >>>>>>> >>>>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has >>>>>>> become the de-facto standard, so it would make sense to support >>>>>>> it bidirectionally with Pillar. >>>>>>> >>>>>>>> The readme.md that Peter is talking about is gfm markdown >>>>>>> Well, technically it is just a CommonMark, as I am not using any >>>>>>> github extensions. >>>>>>> (Github uses CommonMarks and adds just couple small extensions.) >>>>>>> >>>>>>> Peter >>>>>>> >>>>>> >>>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> âLive like you mean it." >>> >>> >> >> >

Aug. 14, 2017

Re: [Pharo-dev] Fuel fails in squeak

by henry

I am coding in Squeak as I am unable to load in Pharo, as previously mentioned. I will investigate Fuel versions, thank you. - HH On Mon, Aug 14, 2017 at 13:36, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I checked and in Pharo 60 MCSmalltalkhubRepository owner: 'Pharo' project: 'Fuel' user: '' password: '' Now Fuel is by default loaded into Pharo so may be you have another scenario. Stef On Mon, Aug 14, 2017 at 7:02 PM, henry wrote: > I loaded the latest Fuel from squeak source and it fails when materializing > a Character from a FixedObjectCluster. Character class does not support > basicNew. > > Helpful>?? > > - HH > > @callistohouse.club>

Aug. 14, 2017

Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript?

by Frank-B

Hello Craig, this approach just as Bert's VM in the browser is/are certainly technically very interesting projects and now comes the big "BUT": - I see absolutely no sense in this approach for real-world end-user applications - especially if their sources MUST be closely connected with existing Smalltalk code, which does not run in the client like all the data-driven model definitions etc that I already have - the Morph UI is out of any question related to what end-users expect (pardon, but end-users would regard this as a bad joke) - the esponsivness of such a solution in the browser must always be far slower than any "normal" browser UI - and it's impossible to port my >10.000 framwork and application classes to Squeak. There are several more reasons, why this would conflict with my future plans, which I do not want to disclose here. So, I see only academic reasons for this work. I do thank you for your answer. Should my view be copletely wrong, please let me know. Best regards Frank -- View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 14, 2017

Serializers/Encoders

by henry

I find I do not necessarily have a specific question regarding a specific implementations, but a higher-level question of feasible solution. I need substitutable, type-relevant JSON encoding, perhaps based upon JSON Schemas. I am looking at ASN1Modules & types, Fuel clusterings/substitutions and NeoJSON clusters & mappers. Is it feasible to bring all these together? I would use ASN1Types, Fuel graph walking/substitutions and NeoJSON encoding and cluster hooks. Fuel also has Clusters but I see that Fuel encodes these clusters in each encoding. I am torn about this philosophically: good to have self-describing data encoding, but not suitable for JSON, unless just a type-name extension. Lightweight & robust descriptions? Well, this is all Fuel cluster specs within the encoding really is: a type-specification. The aspect of NeoJSON that has me wondering is the lack of polymorphism in type-spec lookup and recursive substitution. This is where Fuel shines, I feel. So what is the vision of the end state encoder? Use ASN1 Types as cluster descriptors, Fuel proxification on materializations and NeoJSON encoding and mappers. Would you have for me guidances in this area? - HH

Aug. 14, 2017