January 2021 - Pharo-users - lists.pharo.org

[ANN] Willow v14.0.0 [v14.0.0] released!

by Buenos Aires Smalltalk

Jan. 23, 2021

Re: Reorganize World menu items - survey

by StÃ©phane Ducasse

> On 20 Jan 2021, at 11:24, DavidBajger <bajger(a)gmail.com> wrote: > > Hi here! > I was proposing survey for Pharo users related to menu re-arrangement, currently implemented by @gcorriga. Relate GH issue here https://github.com/pharo-project/pharo/issues/8198. I will put results of voting to related GH issue then. So here are questions to you (same will be posted on Pharo Discord -> #development channel): > > What would be ideal name for "VCS" top menu item? Menu aggregates all tools related to versioning, source code mgmt, changes, history. Please answer by voting buttons, or propose your own: > 1. "VCS" (keep existing proposal) > 2. "Source" > 3. "Versions" > 4. "Version Control" > 5. "Changes" > (or anything else) Version Control? > > What would be ideal name for "Tools" top menu item? Purpose is to be the default entry point for any non-standard tools that someone might want to have loaded in the image. E.g. if you load Teapot, the two menu items would be found there. Currently will include just Roassal. Options: > 6. "Tools" (keep existing proposal) > 7. "Community" > 8. "3rd Party" > 9. "Other" > 10. "Applications" > (or anything else) Extra Tools? > > Complete overview (screenshots) here: https://github.com/pharo-project/pharo/issues/8198 > David Bajger > > Sent from the Pharo Smalltalk Users mailing list archive <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Jan. 22, 2021

Re: NeoCSVReader and wrong number of fieldAccessors

by jtuchel＠objektfabrik.de

Tim, Am 22.01.21 um 10:22 schrieb Tim Mackinnon: > Iâm not doing any CSV processing at the moment, but have in the past - > so was interested in this thread. > > @Kasper, canât you just use #readHeader upfront, and do the assertion > yourself, and then proceed to loop through your records? It would seem > that the Neo caters for what you are suggesting - and if you want to > add a helper method extension you have the building blocks to already > do this? > This is a good idea. One caveat, however: #readHeader in its current implementation does 2 things: * read the line respecting each field (thereby, respect line breaks within quoted fields - perfect for this purpose) * update the number of Columns for further reading (assuming #readHeader's purpose is to interpret the header line) This second thing is in our way, because it may influence the way the following lines will be interpreted. That is ecactly why I created an issue on github (https://github.com/svenvc/NeoCSV/issues/20 <https://github.com/svenvc/NeoCSV/issues/20>). A method that reads a line without any side effects (other than pushing the position pointer forward to the next line) would come in handy for such scenarios. But you can always argue that this has nothing to do with CSV, because in CSV all lines have the same number of columns, each of them containing the same kind of information, and there may be exactly one header line. Anything else is just some file that may contain CSV-y stuff in it. So I am really not sure if NeoCSV should build lots of stuff for such files. I'd love to have this, but I'd understand if Sven refused to integrate it.... ;-) > The only flaw I can think of, is if there is no header present then I > canât recall what Neo does - ideally throws an exception so you can > decide what to do - potentially continue if the number of columns is > what you expect and the data matches the columns - or you fail with an > error that a header is required. But I think you would always need to > do some basic initial checks when processing CSV due to the nature of > the format? Right. You'd always have to write some specific logic for this particular file format and make NeoCSV ignore the right stuff... Joachim > > Tim > > On Fri, 22 Jan 2021, at 6:42 AM, Kasper Osterbye wrote: >> As it happened, I ran into the exact same scenario as Joachim just >> the other day, >> that is, the external provider of my csv had added some new columns. >> In my case >> manifested itself in an error that an integer field was not an >> integer (because new >> columns were added in the middle). >> >> Reading through this whole thread leaves me with the feeling that no >> matter what Sven >> adds, there is still a risk for error. Nevertheless, my suggestion >> would be to add a >> functionality to #skipHeaders, or make a sister method: >> #assertAndSkipHeaders: numberOfColumns onFailDo: aBlock given the >> actual number of headers >> That would give me a way to handle the error up front. >> >> This will only be interesting if your data has headers of cause. >> >> Thanks for NeoCSV which I use all the time! >> >> Best, >> >> Kasper > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Jan. 22, 2021

Re: NeoCSVReader and wrong number of fieldAccessors

by Tim Mackinnon

Iâm not doing any CSV processing at the moment, but have in the past - so was interested in this thread. @Kasper, canât you just use #readHeader upfront, and do the assertion yourself, and then proceed to loop through your records? It would seem that the Neo caters for what you are suggesting - and if you want to add a helper method extension you have the building blocks to already do this? The only flaw I can think of, is if there is no header present then I canât recall what Neo does - ideally throws an exception so you can decide what to do - potentially continue if the number of columns is what you expect and the data matches the columns - or you fail with an error that a header is required. But I think you would always need to do some basic initial checks when processing CSV due to the nature of the format? Tim On Fri, 22 Jan 2021, at 6:42 AM, Kasper Osterbye wrote: > As it happened, I ran into the exact same scenario as Joachim just the other day, > that is, the external provider of my csv had added some new columns. In my case > manifested itself in an error that an integer field was not an integer (because new > columns were added in the middle). > > Reading through this whole thread leaves me with the feeling that no matter what Sven > adds, there is still a risk for error. Nevertheless, my suggestion would be to add a > functionality to #skipHeaders, or make a sister method: > #assertAndSkipHeaders: numberOfColumns onFailDo: aBlock given the actual number of headers > That would give me a way to handle the error up front. > > This will only be interesting if your data has headers of cause. > > Thanks for NeoCSV which I use all the time! > > Best, > > Kasper

Jan. 22, 2021

Re: NeoCSVReader and wrong number of fieldAccessors

by jtuchel＠objektfabrik.de

Kasper, I think this is somewhat close to another thing I am describing here: https://github.com/svenvc/NeoCSV/issues/20 <https://github.com/svenvc/NeoCSV/issues/20> The problem with extending NeoCSV endlessly is that some of the things we need with "real-life" CSV files is the fact that they are not CSV files at all, so it is hard to tell if it is a good idea to litter NeoCSV with methods for edge cases that have literally to do with the fact that part of our files are not CSV at all... I somehow have the feeling some of what we need is a subclass of Stream that knows about constraints like "a line-break is only the end of a record if it is not part of a quoted field". So I am somewhat torn between wanting that stuff in NeoCSV and not wanting to mix csv parsing with handling of stupid ideas people have when exporting data in some CSV-like file. Maybe it is a good idea to collect a few concepts that have been mentioned in these threads: * Sometimes we want to skip lines (header, footer) without interpreting their contents and without any side effects (not CSV-compliant) * Sometimes we want to ignore "additional data" after the end of a defined number of columns (not CSV-compliant) * Sometimes we need to know which line/column couldn't be parsed correctly (related to CSV and non-CSV) A plus would be if we could add the column name to the error message like in "The column 'amount' in line 34 cannot be interpreted as monetary amount" - but this is surely quite some work! * Sometimes we want to interpret columns by the column names in the header line (which may or may not be the first line of the file, only the former being CSV-compliant) Of course this all doesn't mean I am not a fan of NeoCSV. It is well-written, works very well for "real" CSV and performs very well for my use cases. Most of the things we are talking about here are problems that arise when a CSV-file is not a CSV-file... Joachim Am 22.01.21 um 07:42 schrieb Kasper Osterbye: > As it happened, I ran into the exact same scenario as Joachim just the > other day, > that is, the external provider of my csv had added some new columns. > In my case > manifested itself in an error that an integer field was not an integer > (because new > columns were added in the middle). > > Reading through this whole thread leaves me with the feeling that no > matter what Sven > adds, there is still a risk for error. Nevertheless, my suggestion > would be to add a > functionality to #skipHeaders, or make a sister method: > #assertAndSkipHeaders: numberOfColumns onFailDo: aBlock given the > actual number of headers > That would give me a way to handle the error up front. > > This will only be interesting if your data has headers of cause. > > Thanks for NeoCSV which I use all the time! > > Best, > > Kasper -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Jan. 22, 2021

Re: NeoCSVReader and wrong number of fieldAccessors

by Kasper Osterbye

As it happened, I ran into the exact same scenario as Joachim just the other day, that is, the external provider of my csv had added some new columns. In my case manifested itself in an error that an integer field was not an integer (because new columns were added in the middle). Reading through this whole thread leaves me with the feeling that no matter what Sven adds, there is still a risk for error. Nevertheless, my suggestion would be to add a functionality to #skipHeaders, or make a sister method: #assertAndSkipHeaders: numberOfColumns onFailDo: aBlock given the actual number of headers That would give me a way to handle the error up front. This will only be interesting if your data has headers of cause. Thanks for NeoCSV which I use all the time! Best, Kasper

Jan. 22, 2021

Two year position at RMOD on Pharo and Machine Learning

by StÃ©phane Ducasse

Hello we have a new position at RMOD France to work on machine learning algorithms for Pharo. Please distribute this announce and do not hesitate to contact me for more information. S. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Jan. 21, 2021

Reorganize World menu items - survey

by DavidBajger

Hi here! I was proposing survey for Pharo users related to menu re-arrangement, currently implemented by @gcorriga. Relate GH issue here https://github.com/pharo-project/pharo/issues/8198. I will put results of voting to related GH issue then. So here are questions to you (same will be posted on Pharo Discord -> #development channel): What would be ideal name for "VCS" top menu item? Menu aggregates all tools related to versioning, source code mgmt, changes, history. Please answer by voting buttons, or propose your own: 1. "VCS" (keep existing proposal) 2. "Source" 3. "Versions" 4. "Version Control" 5. "Changes" (or anything else) What would be ideal name for "Tools" top menu item? Purpose is to be the default entry point for any non-standard tools that someone might want to have loaded in the image. E.g. if you load Teapot, the two menu items would be found there. Currently will include just Roassal. Options: 6. "Tools" (keep existing proposal) 7. "Community" 8. "3rd Party" 9. "Other" 10. "Applications" (or anything else) Complete overview (screenshots) here: https://github.com/pharo-project/pharo/issues/8198 ----- David Bajger -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 20, 2021

Re: [ANN] Foliage: a static site generator

by Offray Vladimir Luna CÃ¡rdenas

Hi, Our static site generator explorations last semester led me towards TiddlyWiki for the more dynamic counterpart of such sites. In our case is for creating miniwikis and notes connected with HedgeDoc, the real time Markdown editor we use in our workshops, but that could be just the tip of the iceberg. For example you may be interested in Proyectify[1], from Nicolas, the same author behind Amber Smalltalk: [1] https://projectify.wiki/ What I would like is to use Pharo as a development platform for the TiddlyWiki target/deployment platform, but that's for another thread. Cheers, Offray On 19/01/21 5:29 a.Â m., Norbert Hartl wrote: > Thank you for the kind works. And thank you very much for bring tiddlywiki back to my mind. I was looking into when scanning tools for note taking. But I think this can be an addition for foliage. I will see if it works like I want to be. > > Norbert > > >> Am 19.01.2021 um 00:57 schrieb Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com>: >> >> Pretty cool! Thanks Norbert. BTW I'm using your Mustache library and >> Futures patch for building Brea (explained below), so triple thanks :-). >> >> On a similar front I'm building Brea, which is kind of between a static >> site generators, because it builds a web site from Markdown files >> (thanks to Pandoc) and a deucopled CMS because it provides an API to >> query the site and its data thanks to Fossil. As usual, Pharo glues all >> together and brings dynamic data manipulation. >> >> We have been documenting it pretty actively (in Spanish) in [1] and the >> source code repository is at [2]. Brea follows the self referential >> tradition of Smalltalk/Pharo so the site at [1] is done in Brea. >> >> The idea is pretty simple: a HTML5UP[3] base template site (see [3a]), >> is downloaded and a Mustache template (see [3b]) is build from it so a >> set of Markdown files can be injected in such template to produce the >> correspondent HTML output (see [3c]). Everything is versioned in Fossil, >> which provides us with an integrated web UI with version control. The >> template page can have sparks of JavaScript here and there to extent the >> site functionality (like in JamStack[4] approach). For example, by >> clicking the marker at the top right of the page[5] you can get the >> page comments[5], powered by hypothesis[5b]. Page metadata for such >> extended functionality or linking the page with the repository is stored >> as YAML front page or added at creation time. >> >> The code to install a theme is at [6] and to create a page on [6a]. >> Notice that page creation is only 7 lines, while extra lines are related >> with metadata for extra functionality. >> >> As we advance mainly by community workshops and projects on a voluntary >> basis (and with microgrants like the one of ESUG, which makes a >> macro-difference here), now our community explorations led us more >> towards the dynamic counterpart of web site creation, this time >> combining Fossil, TiddlyWiki and Pharo [7][7a]. So Brea is a little bit >> quiet after last year ending. I hope once we have matured the dynamic >> web site counterpart we can retake this again and build momentum around >> such projects. >> >> So, I think Pharo is getting to an interesting point regarding web site >> generation and is good to have a panoramic overview of what is possible, >> even with this early developments like Foliage and Brea. >> >> Cheers, >> >> Offray >> >> == Links: >> >> [1] https://mutabit.com/repos.fossil/indieweb/ >> [2] https://code.tupale.co/Offray/Brea >> [3] https://html5up.net/ >> [3a] https://html5up.net/editorial >> [3b] >> https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/pagina.mus.html >> [3c] >> https://mutabit.com/repos.fossil/indieweb/tree?ci=trunk&type=tree&name=docs… >> [4] https://jamstack.org/ >> [5] https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/index.html >> [5a] >> https://hyp.is/go?url=https%3A%2F%2Fmutabit.com%2Frepos.fossil%2Findieweb%2… >> [5b] >> [6] http://ws.stfx.eu/OOAPJW34PAWW >> [6a] http://ws.stfx.eu/6990ECTMZRNY >> [7] https://fossil-scm.org/forum/forumpost/c650e4c2cd?t=h >> [7a] >> https://mutabit.com/repos.fossil/offray-blog/uv/bliki/index.html#Portfolio >> >> On 18/01/21 9:11 a. m., Norbert Hartl wrote: >>> Hi, >>> >>> Iâve been toying around with a web site generator the last months. >>> Some people were showing interest and asked me to release it. It is >>> still pretty basic but I manage my blog with it . Iâm all open ears >>> about what you think, what doesnât work and what is missing. >>> >>> Please read about it >>> >>> https://norbert.hartl.name/blog/2021-01-17-foliage-released.html >>> <https://norbert.hartl.name/blog/2021-01-17-foliage-released.html> >>> >>> Hopy you like it, >>> >>> Norbert >>>

Jan. 19, 2021

Re: [ANN] Foliage: a static site generator

by Norbert Hartl

Thank you for the kind works. And thank you very much for bring tiddlywiki back to my mind. I was looking into when scanning tools for note taking. But I think this can be an addition for foliage. I will see if it works like I want to be. Norbert > Am 19.01.2021 um 00:57 schrieb Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com>: > > Pretty cool! Thanks Norbert. BTW I'm using your Mustache library and > Futures patch for building Brea (explained below), so triple thanks :-). > > On a similar front I'm building Brea, which is kind of between a static > site generators, because it builds a web site from Markdown files > (thanks to Pandoc) and a deucopled CMS because it provides an API to > query the site and its data thanks to Fossil. As usual, Pharo glues all > together and brings dynamic data manipulation. > > We have been documenting it pretty actively (in Spanish) in [1] and the > source code repository is at [2]. Brea follows the self referential > tradition of Smalltalk/Pharo so the site at [1] is done in Brea. > > The idea is pretty simple: a HTML5UP[3] base template site (see [3a]), > is downloaded and a Mustache template (see [3b]) is build from it so a > set of Markdown files can be injected in such template to produce the > correspondent HTML output (see [3c]). Everything is versioned in Fossil, > which provides us with an integrated web UI with version control. The > template page can have sparks of JavaScript here and there to extent the > site functionality (like in JamStack[4] approach). For example, by > clicking the marker at the top right of the page[5] you can get the > page comments[5], powered by hypothesis[5b]. Page metadata for such > extended functionality or linking the page with the repository is stored > as YAML front page or added at creation time. > > The code to install a theme is at [6] and to create a page on [6a]. > Notice that page creation is only 7 lines, while extra lines are related > with metadata for extra functionality. > > As we advance mainly by community workshops and projects on a voluntary > basis (and with microgrants like the one of ESUG, which makes a > macro-difference here), now our community explorations led us more > towards the dynamic counterpart of web site creation, this time > combining Fossil, TiddlyWiki and Pharo [7][7a]. So Brea is a little bit > quiet after last year ending. I hope once we have matured the dynamic > web site counterpart we can retake this again and build momentum around > such projects. > > So, I think Pharo is getting to an interesting point regarding web site > generation and is good to have a panoramic overview of what is possible, > even with this early developments like Foliage and Brea. > > Cheers, > > Offray > > == Links: > > [1] https://mutabit.com/repos.fossil/indieweb/ > [2] https://code.tupale.co/Offray/Brea > [3] https://html5up.net/ > [3a] https://html5up.net/editorial > [3b] > https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/pagina.mus.html > [3c] > https://mutabit.com/repos.fossil/indieweb/tree?ci=trunk&type=tree&name=docs… > [4] https://jamstack.org/ > [5] https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/index.html > [5a] > https://hyp.is/go?url=https%3A%2F%2Fmutabit.com%2Frepos.fossil%2Findieweb%2… > [5b] > [6] http://ws.stfx.eu/OOAPJW34PAWW > [6a] http://ws.stfx.eu/6990ECTMZRNY > [7] https://fossil-scm.org/forum/forumpost/c650e4c2cd?t=h > [7a] > https://mutabit.com/repos.fossil/offray-blog/uv/bliki/index.html#Portfolio > > On 18/01/21 9:11 a. m., Norbert Hartl wrote: >> Hi, >> >> Iâve been toying around with a web site generator the last months. >> Some people were showing interest and asked me to release it. It is >> still pretty basic but I manage my blog with it . Iâm all open ears >> about what you think, what doesnât work and what is missing. >> >> Please read about it >> >> https://norbert.hartl.name/blog/2021-01-17-foliage-released.html >> <https://norbert.hartl.name/blog/2021-01-17-foliage-released.html> >> >> Hopy you like it, >> >> Norbert >>

Jan. 19, 2021