December 2017 - Pharo-users

Re: [Pharo-users] Grafoscopio (Initial) Feedback

by Offray Vladimir Luna CÃ¡rdenas

Hi Sean, Thanks for your feedback. I presume that you installed Grafoscopio following the instructions at the SmalltalkHub. They were not updated (they're now), so please follow the updated instructions and tell me how many of the problems you reported persist, as most of them have been solved in future releases of Grafoscopio, including the ones related with auto-update of documentation and the DataViz package. I will check the Metacello script in the readme with more time next week, after holidays. Cheers, Offray On 30/12/17 22:37, Sean P. DeNigris wrote: > Thanks for this exciting project! I'm very intrigued after reading some of > your blog posts because I have been actively working with big data in Pharo, > but mostly by hacking/cobbling things together without a proper > toolset/community. > > Here are a few things I noticed as I started playing around: > - Maybe you should change the load command in the StHub readme to: > ``` > Metacello new > smalltalkhubUser: 'Offray' project: 'Grafoscopio'; > configuration: 'Grafoscopio'; > load. > ``` > - the current script is in an old form > - it also hardcodes Pharo 5 > - This would greatly simplify the load via script instructions in the > manual > - Is it supposed to load in Pharo 6.1? I got `OrderedCollection DNU > #asSymbol from #listOutdatedDocsIn:. I stubbed out #isUpdated to return true > and it loaded. > - Do you have any plans to move to git? I would love to contribute, but I've > been spoiled by GH and I just don't have the energy to go back to the mcz > (barrier filled) contribution process ha ha > - I found the intermixing of gray and color buttons confusing. I assumed > that the gray ones were disabled. > - I wonder if labels on the node title and link edit fields might help > discoverability > - All the export formats seem to end up saving to markdown. I assumed this > is because I'm missing an external library? Either way, it would be good to > get some feedback on why it doesn't work as expected and how to make it > work. > > Thanks again. Keep moving forward!! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Dec. 31, 2017

Re: [Pharo-users] A playground for Markdown?

by Dimitris Chloupis

> I have argued time and again and in length about Markdown support in > Pharo, so I will not do it again. I'll just repeat that, in order to make > Pharo less isolated, Git support for managing software source code has the > strategic importance, in the same way that Markdown support for managing > documentation source code has strategic importance. This doesn't preclude > support for native/alternative DVCS in the software front (Monticello, > Fossil, etc) or markup languages in the documentation one (Pillar, > Dokuwiki, t2tags, etc). > It's kinda funny because me and Esteban have been very early on huge supporters of git and github when the rest of the community was mildly interested to passionately against it. I have been very vocal about it, to the point of annoying people and being accused of just supporting a overhyped product. 4 years later working with git is the official way of doing things and we even have our very own github client in the image. Pandoc has a feature set far, far longer and more important that Pillar and > Markdown, including Yaml metadata blocks, fine grained exportation control, > ePub and a myriad of other output (an input) formats support (see graphic > below), a community that is mostly devoted to discuss extensively/mainly a > lightweight markup language for "full stack" documentation, scholarly > Markdown community for academic writing, annotated Markdown for > collaborative editing and writing, programmable templates, multilingual > scripting support, including embedded one for Lua (which came pretty handy > to import our most recently publication[1][1a]). And that just to mention > some prominent features in the greater feature set that just Pillar or > Markdown provides. As community we need to not blind ourselves to > alternatives and overcome the Not Invented Here Syndrome, to see value in > what is done outside Pharo for documentation in the same way we have done > for software management (specifically Git). > > A playground for Markdown will enhance Pandoc integration, which we > already have in Grafoscopio, but writing medium to long texts in it, using > the current plain text input objects support is cumbersome. Despite that we > have managed to have long book sized texts redone in Grafoscopio in an > agile way. The Data Driven Journalism Handbook [2] has 300+ pages (13 Mb > PDF) in a single Grafoscopio notebook, stored under just a 600kb STON file > (and a 500 kb exported Markdown file). > > [1] > http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBog… > [1a] > http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigit… > [2] http://mutabit.com/repos.fossil/mapeda/ > > Several times, when I ask questions about Markdown, I'm pointed towards > the Pillar existence, and I reiterate/expand my motives for wanting to > implement *Markdown* support in Pharo. This exercise allow me to reiterate > my questions in a more precise manner and hopefully this time someone will > point me to a starting place about how to create a "playground for > Markdown". > > Cheers, > > Offray > My personal opinion on this is that using syntax for documentation in 2017 feels to me like stone age. We did not even do this in 1980. I will dare to predict and you can bookmark this post that Markdow will slowly disappear to be replaced with the proper way of doing documentation and that is through a dedicated documentation editor like Libreoffice. Even Google docs seem to return in favour of Markdown. The wide range of documentation formats take only a tiny fraction of the market. Adobe may have lost the war with Flash but when it comes to PDF they have won and won it easily. EPub for example is the least relevant format nowadays, it used be widely popular format, nowhere near to pdf but popular indeed at the time of PDAs but then iPhone came out and killed it together with Flash. Nowdays is used mostly on Kindle which is also another device that has lost most of its popularity. I consider myself an expert on documentation because my day job is being a lawyer and basically what we do is we write complex technical documentation for courts. Especially my kind of lawyer that do not do criminal law. I am writing legal documentation in a week what takes our community to write in years. Microsoft Office has been monopolising our field to an extreme extend and I must be one of those rare exceptions that I use Libreoffice and quite frankly I dont blame them because it has its issues. No I am not a believer in Markdown which usage became relevant only because Github supported it out of the box. With Github Markdown is nothing. I am not a believer in LaText again, another specialised software that is used by a very specific community. I am not a believe in Pandoc, why bother with a million formats when only 2 dominate the market ? I am not even a believer in doc string apis that exist for creating reference documentation from inside code. Why ? Because either they are unnecessary hard to use or limited to what they can do. If it was up to me, Libreoffice would have been our official way of documentation and the only alternative would have been an in image editor probably leveraging the existing Libreoffice API. I am a GUI guy, anything that helps me type less and visualise more its far better option to the alternatives. But I have never stopped anyone from doing anything nor I tried to discourage. I can guarantee to you the same people that have not embraced Pillar is extremely unlikely they will embrace Markdown and Pandoc. There are two things that coders hate a) Writing documentation b) Creating GUIs. This is not going to change any time soon. Well not this millennium at least. In any case whatever your goal I wish you very good luck. You are going to need it.

Dec. 31, 2017

Re: [Pharo-users] Fuel serialize of 70MB takes forever on Linux vs. Mac

by Andreas Brodbeck

Am 19.12.17 um 12:06 schrieb Mariano Martinez Peck: > On Tue, Dec 19, 2017 at 7:40 AM, Andreas Brodbeck <dassi(a)mindclue.ch> wrote: > > Hi Andreas, > > Reading the thread nothing obvious comes to my mind. Sorry. My guy feeling > is that some of the primitives used by FLLargeIdentityDicitonary become > slower in latest VMs. > I guess the main one to check is #fuelPointsTo: (primitive 132) (see the > senders). Maybe you can do a quick test (isolated from your app) and > compare agains old pharo ? > > Another thing would be comparing your scenario using a identity set. Just > save your image before doing this: > > | set dict | > set := FLLargeIdentitySet. > dict := FLLargeIdentityDictionary. > Smalltalk at: #FLLargeIdentitySet put: IdentitySet. > Smalltalk at: #FLLargeIdentityDictionary put: IdentityDictionary. > > And re-run the serialization. I tried this interchange of FLLarge* with standard dictionaries, like suggested above by Mariano. The results are astonishing: ************************** 240 seconds with FLLarge* classes 111 seconds with standard Pharo classes ************************** Thats a time reduction by more than 50%! Does this mean that FLLarge* classes are obsolete and can be substituted by standard classes? (At least in the newer Pharos versions) Cheers, Andreas -- Andreas Brodbeck www.mindclue.ch

Dec. 31, 2017

Re: [Pharo-users] Grafoscopio (Initial) Feedback

by Sean P. DeNigris

Sean P. DeNigris wrote > Here are a few things I noticed as I started playing around: A few moreâ¦ - `GrafoscopioDocumentation openDatavizIntro` asks me if I want to update the doc, which I confirm, but it doesn't then open the doc unless I evaluate it a second time - `OffshoreLeaksDocs introNotebook` fails because `OffshoreLeaksDocs` doesn't seem to exist in the system. I see `OffshoreLeaksDB>>#updateIntroNotebook` which sounds promising, but leads to `GrafoscopioBrowser` DNU #downloadingFrom:withMessage:into:. I see that GrafoscopioDockingBar does implement it, so I change to that class, but then get: `SizeMismatch: Collections sizes do not match` because aFilenameString is trying to be appended via #/ to a file path, but the path is aString, not aFileReference so execution goes down a weird unproductive rabbit hole. Is there any reason not to pass aFileReference for location? - Related to above, I notice that the remote repo (logically a URL) is also passed around as a string. Is there a reason for that? If it was a real URL (e.g. via aString asUrl), you could replace hand-rolled things like `fileName := (downloadUrl splitOn: $/) last.` with `downloadUrl file` [sigh of relief]. - When I make the changes above to real domain objects, the download succeeds... or does it?! I expected to find the notebook under the image directory like all the other books so far, but it's in ~/Documents/Grafoscopio. Why the difference? - Many of the class side methods of would benefit from annotations - either <gtExample> (e.g. choroplethWorldMap) or <script> (e.g. #downloadWorldMap). Both make the method runnable from the browser, and gtExample has many benefits, the simplest and most immediate of which is bringing up an inspector on the result - Speaking of #downloadWorldMap, the source URL seems to be missing - Twitter - how would one populate with some real data? Okay, enough for now. HTH. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 31, 2017

Re: [Pharo-users] Object Persistence

by Stephane Ducasse

Hi manuel what kind of queries can we express? Can be get select node? Now out of memory is a read falg for me (for moose because we do that all the time). Stef On Tue, Dec 26, 2017 at 10:03 PM, Manuel Leuenberger <leuenberger(a)inf.unibe.ch> wrote: > Iâve always liked Neo4j to persist object graphs. Also has a nice query language. The database is not fool-proof (isolation issues, out of memory on expensive queries), but works fine for analytics. > >> On 25 Dec 2017, at 10:43, Ian Ian <icjohnsoia(a)gmail.com> wrote: >> >> Hi All, >> >> Thoughts of a purely OO nature? >> >> :) > >

Dec. 31, 2017

Re: [Pharo-users] Object Persistence

by Stephane Ducasse

We could talk to the guy to see if he wants to revisit the license. and you can decide to load GPL in your app and be happy. I hope that omnibase will be ported to pahro in the future. On Tue, Dec 26, 2017 at 9:30 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > But if VOSS is GPL, that doesn't imply that, when ported, all Pharo > could become GPL, as discussed time and again in the list? > > Cheers, > > Offray > > On 25/12/17 10:01, Stephane Ducasse wrote: >> the author of omnibase told me that he always wanted to port it to >> Pharo. But may be someone should do it. >> There is also VOSS that is open source even if GPL that could be >> ported to pharo but this is an effort too. >> >> Stef >> >> On Mon, Dec 25, 2017 at 10:43 AM, Ian Ian <icjohnsoia(a)gmail.com> wrote: >>> Hi All, >>> >>> Thoughts of a purely OO nature? >>> >>> :) >> > >

Dec. 31, 2017

Re: [Pharo-users] A playground for Markdown?

by Stephane Ducasse

you forget impedence mismatch and reducing accidental complexity. Now I really hope that we will be able to have Pharo inside a dll so that we can embed everywhere and a much better interaction with OS and libraries out there. But if you get access to a C library you have to pay the price of the API exposition and glue. Stef On Sun, Dec 31, 2017 at 4:41 AM, Kjell Godo <squeaklist(a)gmail.com> wrote: > i like Pharo > and i want Pharo to do well and i want to use Pharo > and i like very much all the work being done on Pharo yes > Iâm very impressed and hopeful > and i would not wish for that to slow down > but can Pharo do everything by itself? i donât think so > i used to feel like i could not leave Smalltalk > and andyâs comments and bullet proof correctness > because the outside world was such a barrier to entry > and the outside world was always missing something > that makes Smalltalk essential and so i felt like i > could not use those other things > but if Smalltalk could be added to those other things > then they could be ok and i could see using them > like Racket clojure CommonLisp Shen Coq Haskell SwiProlog > StrawberryProlog Pixie Forth Factor etc Ruby except itâs got a hell > of a syntax > erlang > if Smalltalk could be added to them then they could be ok > but without Smalltalk they look just like hell to me what a > travesty > unusable > i donât like anything that smells like C all the C like like java etc > although turbo C was very nice so they had to kill it get rid of > it > because itâs like they are so inferior and yet everybodyâs > first language is just like the quick sand you sink right into > never to be heard from again because God forbid you > should have to go through that again once is enough > so you sink right in never to be heard from again in any other venue > and itâs like these were just the langs that worked first > they got the network effect first and became the monopoly > and thatâs why people use them because God forbid > for bid that you should learn something new we all say > if Smalltalk could be like the front end of some other things > Racket CommonLisp Shen etc then That is what i want > and Smalltalk could be a back end too for things that it > does well like i want to use gemstone etc > > let everything do what it does best and let them all talk > to each other is what i want > thatâs the BorgLisp idea

Dec. 31, 2017

Re: [Pharo-users] A playground for Markdown?

by Stephane Ducasse

> from one format to another, text is parsed by a reader into pandocâs > intermediate representation of the documentâan âabstract syntax treeâ or > ASTâwhich is then converted by the writer into the target format. The pandoc > AST format is defined in the module Text.Pandoc.Definition in pandoc-types. > > A âfilterâ is a program that modifies the AST, between the reader and the > writer: > > INPUT --reader--> AST --filter--> AST --writer--> OUTPUT > > Filters are âpipesâ that read from standard input and write to standard > output. > """ FYI Pillar has the following architecture Input --Reader -> AST -> (Transformer -> AST)* -Outputers (visitor) -> Save So nothing new under the sun. Notice that we can do several transformation passes like expansions. > BTW you did not say: > Ok guys I want to write a Markdown parser (to contribute to > pillar, which would be cool.) > You said I want to have a playground to edit markdown. This is > quite different to me. > > > Because the second thing (Markdown support inside the Playground) is the one > I want to contribute to Pharo(!), not to Pillar. Contributing should not be > so hard, but each time I bring this theme is an uphill battle in just > getting the initial exploration questions answered (because they're about > Markdown and not about Pillar). So you will code your own text Model, AST, and visitor? Did you see that GT people are using Pillar model for the their editor? I think that Markdown support in Pharo is > healthy for Pharo and a meaningful learning experience for me. At least I > should be able to test that by myself in this community with a little of > support like "hey we have CommonMark inside PettitParser" or "here is how > you increase the Playground Syntax support, by specializing this class". Go ahead and learn. > About the not invented syndrome remarks, why then don't we drop Pharo? > Now if each time we want to install pharo we should install Python, > why not installing lua and Ruby and a bit of Javascript in case. > > > Because is not an all or nothing proposal and it has never been. It's about > Pharo *playing well with* others, not about *being replaced by* others. I > don't see any worth in taking this stuff to the extremes. When someone > advise me Pharo, I don't think that he/she is advising me to drop my > operative system and to run Pharo from bare metal because you go the Pharo > way or the No Way(!). You are exagerating and more important under estimating the COST of using multiple systems. Let me take four simple cases - We spend hours debugging Yaml to embedd bash into a travis (no debugger of course) and we failed while we try to understand why the validator went wrong and did not like space (we tried many many combinations of `"' and more. And gave up. Guille is much better than me and Andrew on bash and we all three failed. - Pillar was using external mustache unix based library and I forced them at that time to use Norbert implementation and we can debug it. We can avoid to have bugs because converting a stream into a file then invoking make then reloading the file. - Looking during two days for a bug in bash script that tells that eveyrthing is ok while one package that should have been loaded was dropped. Now we use metacello instead relying on bash now. Do you want more... I have tons of them like that ... Each time you have a different stack you had another level of complexity and it is not linear but exponential. This is the same with servers and processes. Pillar archetypes were zipped on a Jenkins server that may be blocked from time to time. Smalltalkhub may be slow and the bash will continue without failing and your installation breaks. So we are flushing everything. No more mustache on disc, no more spurious metadata, no more separate server, no more make (see below I was not even able to add one entry to the help), no more cp -r (that is not compatible on different OSes!!!). Just plain pharo as much as possible. # Some shell magic to auto-document the main targets. To have a target appear in # the output, add a short, one-line comment with a double ## on the same line as # the target. # # See http://marmelab.com/blog/2016/02/29/auto-documented-makefile.html .phony: help help: ## Describe the main targets (this list) @echo "Main targets you can build:" @awk -F ':|## *' \ '/^[^\t].+:.*##/ {\ printf " \033[36m%s\033[0m#%s\n", $$1, $$NF \ }' $(MAKEFILE_LIST) \ | column -s# -t @[ -n "$(ALTERNATEPRINTFORMATS)" ] \ && echo "Print format alternatives: pdf $(ALTERNATEPRINTFORMATS)" @echo "Combined format+volume targets: pdfbook, htmlchaptersâ¦" @echo "To make a single specific file/format, ask for it explicitly:" @echo " make $(OUTPUTDIRECTORY)/$(firstword $(CHAPTERS)).pdf" # Check that given variables are set and all have non-empty values, # die with an error otherwise. # # Params: # 1. Variable name(s) to test. # 2. (optional) Error message to print. # # See http://stackoverflow.com/questions/10858261/abort-makefile-if-variable-not-… check_defined = \ $(strip $(foreach 1,$1, \ $(call __check_defined,$1,$(strip $(value 2))))) __check_defined = \ $(if $(value $1),, \ $(error Undefined setting $1$(if $2, ($2)))) > You are under estimating the effort that we put in Pillar. We > extracted pillar from pier to be able to have an autonomous document > system with which we can write good pdf and good HTML for > documentation point of view. Because people did not like to write in > LaTeX. > Now if we would stop something each time somebody mention something > else we would be doing python, Javascript or ... > all the time. > > > I don't underestimate anyone's work. Nor in Pillar, nor in Pharo, nor in > Pandoc. In fact trying to make them work better together and giving back to > this community by making software with Pharo and teaching people Pharo (for > free) are clear examples of my appreciation for the work done in several > fronts, inside and outside Pharo. The choice of LaTeX and HTML in your case, > shows practical appreciation for those formats and I don't think that we > should reimplement them in Pharo (despite of several advantages of live > objects as documents instead of dead-files). Instead of putting valuations I > have never done on me, I would advice to try seeing worth in the reasons > behind a lot of people outside this community is using (Pandoc's) Markdown > for documentation and the added value that adding Markdown support brings by > having more people exposed to Pharo ecosystem, ideas, community, values and > technology. The argument that Coca cola is good because many people drink it does not hold. You see Pythoners have their own systems with their own syntax. So what? Pandoc is the same as Pillar. I do not care about the Pillar syntax. I care that this is implemented in Pharo. Now I will not write a markdown parser myself because I have what I need. if other people propose a not super complex parser for markdown then we can integrate it and let people use their own. > So yes I'm dense and I focus on my stuff and my stuff is Pharo. > And yes I do not care about pandoc because I want to write my > exporters and tools in Pharo and I will fight for that. > > > But we don't need to fight for that. Yes because we should do the web in Javascript and the math in R and .... This is always like that. I value your decisions and work and I > think that is healthy to ask for reciprocity and build from that, instead of > wasting time because we don't think the same. Diversity is healthy in a > community. The only thing I'm asking for (besides such reciprocity) is > pointers to start *my* exploration. Then explore. You can also learn from Pillar :) If you want to have a look the pipeline in version 5 is obscrure and in the new pipeline guille dramatically cleaned it. and we will continue. > > This is why I want to use Scale instead of *&%*^)&%^ bash. > And this is why I spent most of time trying to improve Pharo because > it is not at the level I want but I can contribute > and make it better. > > Stef > > > I don't use bash or Json config files for anything related with > documentation in Grafoscopio. Just plain Pharo inside an interactive > "%metadata" playground node in the Grafoscopio notebook. Spoon, Coral, > Scale, would be welcomed when integration with them is ready. I spent good > time also trying to make my contributions and improvements to Pharo. We > don't need to fight because our ways of contribution are different. Ok try and learn. > > Cheers, > > Offray

Dec. 31, 2017

Re: [Pharo-users] A playground for Markdown?

by Kjell Godo

i like Pharo and i want Pharo to do well and i want to use Pharo and i like very much all the work being done on Pharo yes Iâm very impressed and hopeful and i would not wish for that to slow down but can Pharo do everything by itself? i donât think so i used to feel like i could not leave Smalltalk and andyâs comments and bullet proof correctness because the outside world was such a barrier to entry and the outside world was always missing something that makes Smalltalk essential and so i felt like i could not use those other things but if Smalltalk could be added to those other things then they could be ok and i could see using them like Racket clojure CommonLisp Shen Coq Haskell SwiProlog StrawberryProlog Pixie Forth Factor etc Ruby except itâs got a hell of a syntax erlang if Smalltalk could be added to them then they could be ok but without Smalltalk they look just like hell to me what a travesty unusable i donât like anything that smells like C all the C like like java etc although turbo C was very nice so they had to kill it get rid of it because itâs like they are so inferior and yet everybodyâs first language is just like the quick sand you sink right into never to be heard from again because God forbid you should have to go through that again once is enough so you sink right in never to be heard from again in any other venue and itâs like these were just the langs that worked first they got the network effect first and became the monopoly and thatâs why people use them because God forbid for bid that you should learn something new we all say if Smalltalk could be like the front end of some other things Racket CommonLisp Shen etc then That is what i want and Smalltalk could be a back end too for things that it does well like i want to use gemstone etc let everything do what it does best and let them all talk to each other is what i want thatâs the BorgLisp idea

Dec. 31, 2017

Grafoscopio (Initial) Feedback

by Sean P. DeNigris

Thanks for this exciting project! I'm very intrigued after reading some of your blog posts because I have been actively working with big data in Pharo, but mostly by hacking/cobbling things together without a proper toolset/community. Here are a few things I noticed as I started playing around: - Maybe you should change the load command in the StHub readme to: ``` Metacello new smalltalkhubUser: 'Offray' project: 'Grafoscopio'; configuration: 'Grafoscopio'; load. ``` - the current script is in an old form - it also hardcodes Pharo 5 - This would greatly simplify the load via script instructions in the manual - Is it supposed to load in Pharo 6.1? I got `OrderedCollection DNU #asSymbol from #listOutdatedDocsIn:. I stubbed out #isUpdated to return true and it loaded. - Do you have any plans to move to git? I would love to contribute, but I've been spoiled by GH and I just don't have the energy to go back to the mcz (barrier filled) contribution process ha ha - I found the intermixing of gray and color buttons confusing. I assumed that the gray ones were disabled. - I wonder if labels on the node title and link edit fields might help discoverability - All the export formats seem to end up saving to markdown. I assumed this is because I'm missing an external library? Either way, it would be good to get some feedback on why it doesn't work as expected and how to make it work. Thanks again. Keep moving forward!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 31, 2017