November 2017 - Pharo-users

Re: [Pharo-users] I18n in pharo

by Stephane Ducasse

Hi Pavel Does it make sense to have loaded by default? Stef On Fri, Nov 10, 2017 at 8:05 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > 2017-11-09 23:50 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> I think this is two different problems: >> >> 1. pharo itself supporting different languages/keyboards, etc. >> 2. pharo allowing the development of i18n applications >> >> I think we still need to work on point 1, but for point 2 we already have >> gettext package, which is a standard we can/should use. Maybe that needs to >> be better documented (as everything), but wellâ¦ we have a solution there :) > > > Will we include it into the standard image? > > -- Pavel > >> >> Esteban >> >> > On 9 Nov 2017, at 18:58, Torsten Bergmann <astares(a)gmx.de> wrote: >> > >> > The Pharo 7/8 roadmap does not (yet) include I18N: >> > https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/R… >> > >> > and the Pharo core image still includes the "NaturalLanguageTranslator" >> > solution still from Squeak. See this class for more details and >> > all senders of #translated message. So far the whole Pharo UI is in >> > English and while books, the mooc or others were translated the Pharo >> > image so far is not. >> > I guess some more work would be needed also on the font frontier to >> > provide an internationalized image and the different languages. >> > >> > >> > >> > But for own applications (like web applications) there are some more >> > (external) solutions: >> > >> > >> > 1. I once wrote and announced an own I18N framwork: >> > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/1… >> > which is fully documented on >> > http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely >> > proprietary solution. >> > >> > 2. There is also some stuff from Jan van de Sandt: >> > >> > https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.h… >> > >> > 3. And there is GetText (from Seaside web framework) which I guess is >> > either here http://smalltalkhub.com/#!/~PharoExtras/Gettext >> > or now maintained here: >> > https://github.com/SeasideSt/Seaside/wiki/Gettext >> > >> > Unfortunately back at the time this one was not independently loadable >> > and had other trouble which I critisized on >> > http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html >> > >> > Maybe situation for this project has improved. >> > >> > >> > But so far nobody pushed I18N really into Pharo ... >> > >> > 4. Therefore back in 2014 I started with a consolidation by starting a >> > clean room implementation of Gettext - based on code from 3. >> > but now with tests and Pharo Spec based tools (see screenshot >> > attached). I did it in an own repo to be able to experiment and >> > not break the Seaside solution right in the beginning. >> > >> > My code is on STHub >> > http://smalltalkhub.com/#!/~TorstenBergmann/Gettext and it is not yet fully >> > usable and so far still >> > unfinished >> > >> > But one can load the project still in Pharo 7 using >> > >> > Gofer it >> > smalltalkhubUser: 'TorstenBergmann' project: 'Gettext'; >> > configuration; >> > load. >> > >> > (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load >> > >> > All 11 Tests are green so at least what is there should work. Check >> > the world menu and the code. Load the "Foo" package from the same repository >> > to see something in the tools. The idea was to have support for MO and >> > PO files completely written in Smalltalk as well as tools that allow you >> > to find and translate internationalized text. >> > >> > But as always: this would require more work. I would still favour a >> > fully in Pharo written solution (following the gettext formats) but maybe >> > for >> > performance reasons then also bind to libgettext using UFFI. >> > >> > >> > Hope this gives some insights on the current existing solutions/status. >> > >> > Thanks >> > Torsten >> > >> > >> >> Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr >> >> Von: "ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²" <vikenti.potapov(a)gmail.com> >> >> An: pharo-users(a)lists.pharo.org >> >> Betreff: [Pharo-users] I18n in pharo >> >> >> >> >> >> Will Pharo 7 be ready for i18n of applications? >> >> I mean some simple and useful way like in Cincom Visual Works, where >> >> translation dictionaries are separated from code and could be dinamycally >> >> changed without changing my application. >> >> >> >> It is very important for huge commercial applications, especially with >> >> lots of UI forms, dialogs and user-messages. >> >> >> >> I transfer my code from Cincom VW (VW is not available now for Russia >> >> due to politic situation) to Pharo and is very interested in simple >> >> internationalization mechanism. I don't want to reinvent the wheel but >> >> sometimes it seems to me that pharo developers are forced to do it. >> >> >> >> By the way, the error i had last week with clean Pharo 6\Pharo 6.1 >> >> installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - >> >> error caused by cyrillic path to application folder) didn't solved and i had >> >> no feedback from community. >> >> >> >> best regards, >> >> Vikenti Potapov. >> >> >> >> >> > <GetTextNewTools.png> >> >> >

Nov. 11, 2017

Re: [Pharo-users] I18n in pharo

by Stephane Ducasse

Hi torsten Thanks for your summary. I was lost with all the efforts around. Two points: - I do not think that Pharo IDE should be multilingual - I would love to have one or two strong solutions for Application internationalisation. Now Questions: - what do you mean by propretiary solution. The license is MIT. - I think that it would be good to have your solution and getText ready to be loaded and for me this would be nice. Now I have a question how people developing seaside components manage to have internationalised version? Stef On Thu, Nov 9, 2017 at 10:58 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > The Pharo 7/8 roadmap does not (yet) include I18N: https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/R… > > and the Pharo core image still includes the "NaturalLanguageTranslator" solution still from Squeak. See this class for more details and > all senders of #translated message. So far the whole Pharo UI is in English and while books, the mooc or others were translated the Pharo > image so far is not. > I guess some more work would be needed also on the font frontier to provide an internationalized image and the different languages. > > > > But for own applications (like web applications) there are some more (external) solutions: > > > 1. I once wrote and announced an own I18N framwork: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/1… > which is fully documented on http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely proprietary solution. > > 2. There is also some stuff from Jan van de Sandt: > https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.h… > > 3. And there is GetText (from Seaside web framework) which I guess is either here http://smalltalkhub.com/#!/~PharoExtras/Gettext > or now maintained here: https://github.com/SeasideSt/Seaside/wiki/Gettext > > Unfortunately back at the time this one was not independently loadable and had other trouble which I critisized on > http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html > > Maybe situation for this project has improved. > > > But so far nobody pushed I18N really into Pharo ... > > 4. Therefore back in 2014 I started with a consolidation by starting a clean room implementation of Gettext - based on code from 3. > but now with tests and Pharo Spec based tools (see screenshot attached). I did it in an own repo to be able to experiment and > not break the Seaside solution right in the beginning. > > My code is on STHub http://smalltalkhub.com/#!/~TorstenBergmann/Gettext and it is not yet fully usable and so far still > unfinished > > But one can load the project still in Pharo 7 using > > Gofer it > smalltalkhubUser: 'TorstenBergmann' project: 'Gettext'; > configuration; > load. > > (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load > > All 11 Tests are green so at least what is there should work. Check the world menu and the code. Load the "Foo" package from the same repository > to see something in the tools. The idea was to have support for MO and PO files completely written in Smalltalk as well as tools that allow you > to find and translate internationalized text. > > But as always: this would require more work. I would still favour a fully in Pharo written solution (following the gettext formats) but maybe for > performance reasons then also bind to libgettext using UFFI. > > > Hope this gives some insights on the current existing solutions/status. > > Thanks > Torsten > > >> Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr >> Von: "ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²" <vikenti.potapov(a)gmail.com> >> An: pharo-users(a)lists.pharo.org >> Betreff: [Pharo-users] I18n in pharo >> >> >> Will Pharo 7 be ready for i18n of applications? >> I mean some simple and useful way like in Cincom Visual Works, where translation dictionaries are separated from code and could be dinamycally changed without changing my application. >> >> It is very important for huge commercial applications, especially with lots of UI forms, dialogs and user-messages. >> >> I transfer my code from Cincom VW (VW is not available now for Russia due to politic situation) to Pharo and is very interested in simple internationalization mechanism. I don't want to reinvent the wheel but sometimes it seems to me that pharo developers are forced to do it. >> >> By the way, the error i had last week with clean Pharo 6\Pharo 6.1 installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - error caused by cyrillic path to application folder) didn't solved and i had no feedback from community. >> >> best regards, >> Vikenti Potapov. >> >> >>

Nov. 11, 2017

Re: [Pharo-users] I18n in pharo

by Andrew Glynn

Thereâs an online translation service for XLIff files (well, thereâs quite a few but most Iâve found use human translators, and as a result cost a fair bit). Itâs not free either, but for 2-3 languages itâs relatively reasonable at $19/mo., and a couple of monthsâ subscription would allow for a fair number of automated translations which could be quickly tweaked. https://lingohub.com/pricing/ Mojito allows you to integrate the Xliff translation as part of a Travis CI build. Itâs written in Java but supports localization for a number of languages, which implies it wouldnât take much modification to support Pharo. https://github.com/box/mojito Thereâs also a number of Xliff editors on GitHub, including a plugin for Oxygen XML, which I happen to use when I do edit XML rather than using IADS with SGML and exporting XML. Not sure if this is the kind of thing youâre looking for, but it might be a quick way to get key applicationsâ text translated and be used by a relatively simple Pharo / Seaside tool. Itâs even possible that a decent modification of Mojito might allow semi-automated translations using LingoHub. Andrew Glynn From: Andrew Glynn Sent: Friday, November 10, 2017 6:09 PM To: Any question about pharo is welcome Subject: RE: [Pharo-users] I18n in pharo Iâd think about porting the I18n Gem from Ruby but replacing Gettext with xliff to be a better, more generalized solution.Â Cascade in the Ruby Gem is a useful feature missing from other implementations Iâve used. https://github.com/svenfuchs/i18n/tree/master/test http://docs.oasis-open.org/xliff/xliff-core/xliff-core.html It would also likely be easier and more reliable, since the XML support in Pharo is already quite good. Andrew Glynn Sent from Mail for Windows 10 From: Torsten Bergmann Sent: Thursday, November 9, 2017 4:59 PM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] I18n in pharo The Pharo 7/8 roadmap does not (yet) include I18N: https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/R… Â and the Pharo core image still includes the "NaturalLanguageTranslator" solution still from Squeak. See this class for more details and all senders of #translated message. So far the whole Pharo UI is in English and while books, the mooc or others were translated the Pharo image so far is not. I guess some more work would be needed also on the font frontier to provide an internationalized image and the different languages. But for own applications (like web applications) there are some more (external) solutions: 1. I once wrote and announced an own I18N framwork:Â http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/1… Â Â which is fully documented on http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely proprietary solution. 2. There is also some stuff from Jan van de Sandt: Â Â https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.h… 3. And there is GetText (from Seaside web framework) which I guess is either here http://smalltalkhub.com/#!/~PharoExtras/Gettext Â Â or now maintained here: https://github.com/SeasideSt/Seaside/wiki/Gettext Â Â Unfortunately back at the time this one was not independently loadable and had other trouble which I critisized on Â Â Â http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html Â Â Maybe situation for this project has improved. But so far nobody pushed I18N really into Pharo ... 4. Therefore back in 2014 I started with a consolidation by starting a clean room implementation of Gettext - based on code from 3. Â Â but now with tests and Pharo Spec based tools (see screenshot attached). I did it in an own repo to be able to experiment and Â Â not break the Seaside solution right in the beginning. Â Â My code is on STHubÂ http://smalltalkhub.com/#!/~TorstenBergmann/GettextÂ and it is not yet fully usable and so far still Â Â Â unfinished Â Â But one can load the project still in Pharo 7 using Â Â Â Â Gofer it Â Â Â Â Â Â Â smalltalkhubUser: 'TorstenBergmann' project: 'Gettext'; Â Â Â Â Â Â configuration; Â Â Â Â Â Â load. Â Â Â Â (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load Â Â All 11 Tests are green so at least what is there should work. Check the world menu and the code. Load the "Foo" package from the same repository Â Â Â to see something in the tools. The idea was to have support for MO and PO files completely written in Smalltalk as well as tools that allow you Â Â Â to find and translate internationalized text. Â Â But as always: this would require more work. I would still favour a fully in Pharo written solution (following the gettext formats) but maybe for Â Â performance reasons then also bind to libgettext using UFFI. Hope this gives some insights on the current existing solutions/status. Thanks Torsten > Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr > Von: "ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²" <vikenti.potapov(a)gmail.com> > An: pharo-users(a)lists.pharo.org > Betreff: [Pharo-users] I18n in pharo > > > Will Pharo 7 be ready for i18n of applications? > I mean some simple and useful way like in Cincom Visual Works, where translation dictionaries are separated from code and could be dinamycally changed without changing my application. > > It is very important for huge commercial applications, especially with lots of UI forms, dialogs and user-messages. > > I transfer my code from Cincom VW (VW is not available now for Russia due to politic situation) to Pharo and is very interested in simple internationalization mechanism. I don't want to reinvent the wheel but sometimes it seems to me that pharo developers are forced to do it. > > By the way, the error i had last week with clean Pharo 6\Pharo 6.1 installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - error caused by cyrillic path to application folder) didn't solved and i had no feedback from community. > > best regards, > Vikenti Potapov. > > >

Nov. 11, 2017

Re: [Pharo-users] Unable to load SmaCC on pharo6 (or pharo5)

by Thierry Goubier

Hi Steff, Le 10/11/2017 Ã 19:17, Stephane Ducasse a Ã©critÂ : > Hi thierry > > we are working and soon we will have a much simpler installation and > everything :) Out of a minimal image? That would be very cool. > Now just commit and I will check and fix :) I committed, created a pull request and merged. It should be Ok apart from: - can hyphenating be desactivated in ==sequences==? It is allways strange to see a class name or a method name split by a hypen, like in SmaCC-Parser - how does one writes a reference to a section or a chapter? Thierry > > Stef > > On Fri, Nov 10, 2017 at 6:47 AM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: >> Le 09/11/2017 Ã 21:02, Stephane Ducasse a Ã©crit : >>> >>> Yes thierry :) your turn now :) >> >> >> That's will be harder than I expected. I have issues in the LaTeX setup used >> by the booklet. >> >> Thierry >> >> >>> >>> Stef >>> >>> On Thu, Nov 9, 2017 at 8:41 PM, Thierry Goubier >>> <thierry.goubier(a)gmail.com> wrote: >>>> >>>> Le 09/11/2017 Ã 20:15, Federico.Balaguer a Ã©crit : >>>>> >>>>> >>>>> I am following this tutorial >>>>> >>>>> >>>>> >>>>> http://files.pharo.org/books-pdfs/booklet-Smacc/2017-05-05-Smacc-Spiral.pdf >>>>> >>>>> I typed the first example and when I try to compile either LR(1) or >>>>> LALR(1) >>>>> there is a pop-up saying that both clases where not specified. I also >>>>> tried >>>>> adding the classes for the scanner and parser manually but I got the >>>>> result. >>>> >>>> >>>> >>>> Yes. I changed the GUI and that means I need to update the booklet. >>>> >>>> This part: >>>> >>>> â¢ Edit the definition the pane below the compile LR(1) buttons. >>>> â¢ Once you are done: >>>> â Click on the Scanner class and type ExpressionScanner. >>>> â Click on the Parser class and type ExpressionParser. >>>> â¢ press either Compiler LR(1) or Compiled LALR(1) buttons. >>>> >>>> Should now be: >>>> >>>> â¢ Edit the definition the pane below the compile LR(1) buttons. >>>> â¢ Once you are done: >>>> â Type ExpressionParser and return in the text field left of Parser:. >>>> â¢ press either Compiler LR(1) or Compiled LALR(1) buttons. >>>> >>>>> There are a couple other things in the tutorial at the very start that >>>>> didn't add up. I can send an annotated pdf if that is of any help >>>> >>>> >>>> >>>> Yes, that would be very helpfull! >>>> >>>> Thanks, >>>> >>>> Thierry >>>> >>>> >>>>> >>>>> Thanks!! >>>>> >>>>> Federico >>>>> >>>>> >>>>> >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

Nov. 11, 2017

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

by Tudor Girba

Hi, > On Nov 10, 2017, at 9:20 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tudor Girba-2 wrote >> As shown at ESUG, GT Documenter offers an advanced viewer (and editor) for >> Pillar working on top of Bloc. > > Two questions after playing with it: > 1. Can one save a live-edited file? The saving action is not implemented yet. > 2. Is it possible to make the markup codes invisible? That would seem more > appropriate e.g. in a read-only context. That would be another renderer, but it is not difficult to build. That is something weâll do soon. Cheers, Doru > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > -- www.tudorgirba.com www.feenk.com "Beauty is where we see it."

Nov. 11, 2017

smalltalkhub amber debugger

by Sebastian Heidbrink

Hi! I just browsed to http://smalltalkhub.com/#!/~jhoncc2 And got an amber debugger. ShTimelineEvent class from: json Â Â Â ^(self withAllSubclasses Â Â Â Â Â Â detect: [:each | each type = (json at: 'type')] Â Â Â Â Â Â ifNone: [self]) fromJson: json json is nil here! Cheers! Sebastian

Nov. 11, 2017

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

by Ben Coman

On Sat, Nov 11, 2017 at 4:20 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Tudor Girba-2 wrote > > As shown at ESUG, GT Documenter offers an advanced viewer (and editor) > for > > Pillar working on top of Bloc. > > Two questions after playing with it: > 1. Can one save a live-edited file? > 2. Is it possible to make the markup codes invisible? That would seem more > appropriate e.g. in a read-only context. > Which markup codes do you mean? Markup like this still conveys useful information in text mode... ""this is important"" cheers -ben > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Nov. 10, 2017

Re: [Pharo-users] Please consider Apache Integration of Services

by henry

The advantage I see is enabling Smalltalk to be a real open-source player in BigData. All the modern corporations are using the cloud for BigData. The internet companies of the twenty-teens developed all of this software for back-office and middleware processing and Smalltalk does not rank highly on used languages. What is the future and where is Smalltalk in that future. I love Smalltalk and I think about this. Smalltalk has the best development environment but other languages are not far off. Being the most creative development environment does not win contracts. So I think an analysis is useful. Client apps are slim pickings, what with so many options. In reality, nuclear power stations, banks and government bureaucracy are all using web interfaces to their business apps. The retail market is governed by smart phones and playstations. We can't make a phenomenal jump to prominence in those areas I just do not believe. Another way to look is which areas of computing has the most market-place velocity and acceleration. Hands down that is BigData and the cloud management of services. Along with these areas are vast standardizations of data structure definition, what with XML, JSON, Avro and the like. I just found Apache Thrift, a compiled language for data interfaces. Perhaps that should be a target. We can't do everything, but it would be great to see Squeak and Pharo in the list of languages that support pieces of this architecture. The advantages to Storm are introductory. Some combinations of technologies may be more performant but that is no longer the key paramer, what with 100s of partitions forking data to different pipelines to process in massive parallel. Add to this the rise of machine learning upon all of this data flow. Note I said data flow, because half of these new technology architectures is in stream processing while the other is query analytics after the data has been captured. Do we agree here? The key is encoding. I thought the advantage to adopting Storm interoperability was to be: 1 - language placement as feasible in interoperability 2 - initial encoding standards (Avro, so on) 3 - Participation in BigData 4 - solidify capability on the stream side 5 - gateway to operating on the query side This is the future of computing in a significant space where we are not really playing. Ruby is ahead because they can interoperate. I was hoping to encourage a combined coordinated effort towards creating a set of backoffice tools, one each. Currently, I read of three of so different windowing and rendering systems, why all the duplicated efforts there at the expense of integrating with other environments? That seems to be key, to me. Perhaps a better choice to start than Storm? I submit as merely the initial suggestion to coalesce focus, to the backoffice smalltalk consortium. - HH > -------- Original Message -------- > Subject: RE: [Pharo-users] Please consider Apache Integration of Services > Local Time: November 10, 2017 5:55 PM > UTC Time: November 10, 2017 10:55 PM > From: aglynn42(a)gmail.com > To: henry <henry(a)callistohouse.club>, Any question about pharo iswelcome <pharo-users(a)lists.pharo.org> > > From the (admittedly not huge) testing Iâve done, Storm is slower, has more overhead, and more issues with concurrency than simply using the PostgreSQL overlay to HDFS. > > It would also be easier to do using Gemstone and Pivotal HDB than using Storm, since the code to do from Gemfire is already open source and massively smaller than the code to Storm (or Spark - the main difference is the higher level API). > > Since I donât see the advantage, what advantage to you see in it? > > Itâs just my $0.02, and given we no longer have five cent coins in Canad, you can round it to what itâs probably worth â¦ > > Andrew Glynn > > Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 > > From: [henry](mailto:henry@callistohouse.club) > Sent: Friday, November 10, 2017 5:12 PM > To: [Squeak-dev](mailto:squeak-dev@lists.squeakfoundation.org); [Pharo-users list](mailto:pharo-users@lists.pharo.org) > Subject: [Pharo-users] Please consider Apache Integration of Services > > Note, my quote below, Storm is implementable by any language, hello Smalltalk! > > At the risk of throwing a rock in the pool, I must as well acknowledging the unique offerings we have in Smalltalk spaces. The challenge as I see it is the lack of a coordinated effort to adopt common interfaces used in industry. I would hold up the history of the Cryptography team how different folks came together to join efforts in creating a shared library. Which they did. It holds up over the test of time and is ported through multiple Smalltalk environments. Using that as a reference, were the various cloud and BigData applications be seen as worthy to build good integration with, the access to all the great data-manipulation tools and presentations that Smalltalk environments offer will finally be accessible to put on the table in corporate and advanced data processing environments. > > Alright, you may accept what I have been saying then for those of us still in contemplation will be curious about what work that entails. Allow me to present a few of the projects working together through Apache Foundation. They are truly leaders in creating the computing of BigData. The core architecture that is commonly used in BigData and Cloud is called the Lambda Architecture, consisting of a fault-tolerant event streaming source, such as Apache Kafka [1], a batch-processing pipe and NoSQL database coordinator, such as Apache Cassandra [2], and a real-time processing pipe, for example Apache Storm [3]. There is also analytics on the other side of storage, such as through Cassandra to Hadoop and queries. What I would like to highlight is Apache Storm. > > Apache Storm is quite simple in idea though more complex on hardware. One thing to keep in mind is that the fault-tolerance requirement has forced Kafka and Storm to both be replication centric in a de-centralized way. They tend to use Apache Zookeeper [4] to monitor progress through durable queues of data. Storm in particular is a way to consume streams of events, including the ability to join and filter them. Here are two blurbs, one about Storm Architecture and the other about how other languages can implement Storm architecture pieces, especially Bolts. > > My question is why can't and why shouldn't Smalltalks (Pharo, Squeak, Gemstone, Smalltalk Express, Swift, ST/X, Dolphin) be able to participate? Working software engineers are building this stuff and lots of time and money are being spent converting critical data in industry. It seems now is the time to jump aboard as much computing will be done in these areas and we can compete! Here are blurbs about Storm then links to Kafka [1], Cassandra [2] and Storm [3]. > > ------ > > "There are just three abstractions in Storm: spouts, bolts, and topologies. A spout is a source of streams in a computation. Typically a spout reads from a queueing broker such as Kestrel, RabbitMQ, or Kafka, but a spout can also generate its own stream or read from somewhere like the Twitter streaming API. Spout implementations already exist for most queueing systems. > > A bolt processes any number of input streams and produces any number of new output streams. Most of the logic of a computation goes into bolts, such as functions, filters, streaming joins, streaming aggregations, talking to databases, and so on. > > A topology is a network of spouts and bolts, with each edge in the network representing a bolt subscribing to the output stream of some other spout or bolt. A topology is an arbitrarily complex multi-stage stream computation. Topologies run indefinitely when deployed." > > ------ > > "Storm was designed from the ground up to be usable with any programming language. At the core of Storm is a [Thrift](http://thrift.apache.org/) [definition](https://github.com/apache/storm/blob/master/storm-core/src/stor… for defining and submitting topologies. Since Thrift can be used in any language, topologies can be defined and submitted from any language. > > Similarly, spouts and bolts can be defined in any language. Non-JVM spouts and bolts communicate to Storm over a [JSON-based protocol](http://storm.apache.org/documentation/Multilang-protocol.html) over stdin/stdout. Adapters that implement this protocol exist for [Ruby](https://github.com/apache/storm/blob/master/storm-multilang/ruby/src/…, [Python](https://github.com/apache/storm/blob/master/storm-multilang/python/…, [Javascript](https://github.com/apache/storm/blob/master/storm-multilang/jav…, [Perl](https://github.com/dan-blanchard/io-storm)." > > ------ > > [1] https://kafka.apache.org/ > > [2] http://cassandra.apache.org/ > > [3] http://storm.apache.org/ > > [4] https://zookeeper.apache.org/ > > - HH

Nov. 10, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Ben Coman

The CI sometimes fails due to heisenbugs, which of course we should fix but mostly someone just kicks the CI off again and the test passes and the code is integrated. So these heisenbugs slow down development when the CI fails, and also we are not gaining any systematic statistics on where the heisenbugs come from. So for a while I've thought it would be useful for the CI to automatically rerun a failed test to bypass the heisenbugs and at the same time log them to a central location for anaylsis. So I think such a feature could also suit this situation. After you correct the code and resume execution to the end, the test is automatically rerun and turns green, or fails again bringing you straight back to the debugger. Actually that last itself would be a useful feature for a tight cycle dev/testing a Test. cheers -ben On Sat, Nov 11, 2017 at 3:45 AM, Richard Sargent < richard.sargent(a)gemtalksystems.com> wrote: > I hear you and I understand your pain. > > However, if you corrected the problem, not by a code change, but by > playing in the object's inspector or otherwise causing its internal state > to change, and then resumed from the debugger, would you still claim the > method was successful and should be coloured green? > > The only thing we can claim is that there were or were not further errors > in the test. Colour it red if there were, but you cannot honestly colour it > green. The code doesn't actually work. > > > On Fri, Nov 10, 2017 at 11:29 AM, Tim Mackinnon <tim(a)testit.works> wrote: > >> My specific usecase is from a pragmatic TDD perspective - failing test, >> in the debugger you fix the test and press proceed - expecting green. >> Getting red, and then immediately running again to get red takes away from >> our story of love coding and loving your debugger - and even Cassie me to >> mistrust the tools. >> >> I get the idea that you can jiffy in the debugger and cause a false pass >> - but I feel you are penalised for doing it right at the moment. >> >> Of course these tests will get run again, but I like the idea that if I >> did it right, it should recognise this, not incur an extra click and moment >> of doubt. >> >> A button to rerun the whole lot, or automatically rerun, or just run it >> would work for me. >> >> Tim >> >> Sent from my iPhone >> >> On 10 Nov 2017, at 17:56, Richard Sargent <richard.sargent@gemtalksystem >> s.com> wrote: >> >> That would be fine. >> The point is that, without running the test in its entirety, from start >> to finish, without interruption, error, or failure, one cannot claim >> success. >> >> On Fri, Nov 10, 2017 at 9:34 AM, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >> >>> Richard Sargent wrote >>> > The only reliable conclusion one can make from such an interrupted run >>> is >>> > whether it failed again. So, it would be possible to determine that the >>> > test should be coloured red, but it is impossible to *reliably* claim >>> that >>> > the test should be coloured green. >>> >>> What if we ran the test again as if from the browser/runner before >>> setting >>> the icon? >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> >> >

Nov. 10, 2017

Re: [Pharo-users] I18n in pharo

by Andrew Glynn

Iâd think about porting the I18n Gem from Ruby but replacing Gettext with xliff to be a better, more generalized solution. Cascade in the Ruby Gem is a useful feature missing from other implementations Iâve used. https://github.com/svenfuchs/i18n/tree/master/test http://docs.oasis-open.org/xliff/xliff-core/xliff-core.html It would also likely be easier and more reliable, since the XML support in Pharo is already quite good. Andrew Glynn Sent from Mail for Windows 10 From: Torsten Bergmann Sent: Thursday, November 9, 2017 4:59 PM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] I18n in pharo The Pharo 7/8 roadmap does not (yet) include I18N: https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/R… and the Pharo core image still includes the "NaturalLanguageTranslator" solution still from Squeak. See this class for more details and all senders of #translated message. So far the whole Pharo UI is in English and while books, the mooc or others were translated the Pharo image so far is not. I guess some more work would be needed also on the font frontier to provide an internationalized image and the different languages. But for own applications (like web applications) there are some more (external) solutions: 1. I once wrote and announced an own I18N framwork: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/1… which is fully documented on http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely proprietary solution. 2. There is also some stuff from Jan van de Sandt: https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.h… 3. And there is GetText (from Seaside web framework) which I guess is either here http://smalltalkhub.com/#!/~PharoExtras/Gettext or now maintained here: https://github.com/SeasideSt/Seaside/wiki/Gettext Unfortunately back at the time this one was not independently loadable and had other trouble which I critisized on http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html Maybe situation for this project has improved. But so far nobody pushed I18N really into Pharo ... 4. Therefore back in 2014 I started with a consolidation by starting a clean room implementation of Gettext - based on code from 3. but now with tests and Pharo Spec based tools (see screenshot attached). I did it in an own repo to be able to experiment and not break the Seaside solution right in the beginning. My code is on STHub http://smalltalkhub.com/#!/~TorstenBergmann/Gettext and it is not yet fully usable and so far still unfinished But one can load the project still in Pharo 7 using Gofer it smalltalkhubUser: 'TorstenBergmann' project: 'Gettext'; configuration; load. (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load All 11 Tests are green so at least what is there should work. Check the world menu and the code. Load the "Foo" package from the same repository to see something in the tools. The idea was to have support for MO and PO files completely written in Smalltalk as well as tools that allow you to find and translate internationalized text. But as always: this would require more work. I would still favour a fully in Pharo written solution (following the gettext formats) but maybe for performance reasons then also bind to libgettext using UFFI. Hope this gives some insights on the current existing solutions/status. Thanks Torsten > Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr > Von: "ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²" <vikenti.potapov(a)gmail.com> > An: pharo-users(a)lists.pharo.org > Betreff: [Pharo-users] I18n in pharo > > > Will Pharo 7 be ready for i18n of applications? > I mean some simple and useful way like in Cincom Visual Works, where translation dictionaries are separated from code and could be dinamycally changed without changing my application. > > It is very important for huge commercial applications, especially with lots of UI forms, dialogs and user-messages. > > I transfer my code from Cincom VW (VW is not available now for Russia due to politic situation) to Pharo and is very interested in simple internationalization mechanism. I don't want to reinvent the wheel but sometimes it seems to me that pharo developers are forced to do it. > > By the way, the error i had last week with clean Pharo 6\Pharo 6.1 installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - error caused by cyrillic path to application folder) didn't solved and i had no feedback from community. > > best regards, > Vikenti Potapov. > > >

Nov. 10, 2017