- Pharo-users - lists.pharo.org

Re: [Pharo-users] The baseline complexity of tiny big projects...

by Tim Mackinnon

Hi Richard, there isnât an easy way to communicate with Exercism users (Iâm arranging an email to be sent) but essentially just apply this upgrade https://github.com/exercism/pharo-smalltalk/blob/master/docs/UPGRADE.md Sent from my iPhone Sent from my iPhone > On 20 May 2019, at 04:20, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > This is not an answer to your question, but it is an observation by someone who was trying all > the exercises. As a user, it was just working. Then suddenly, there was a change. Instead of > a new exercise popping up underneath Exercism, it would appear as Exercise@Foobar. No big > deal. What *is* a big deal is that the "submit" menu item disappeared, and the only way I > have found to submit a solution is > - File Out the class > - Use the command line to download the exercise > - Move the filed out class to the exercise directly > - exercism submit Foobar.st > I had been quite impressed with how smoothly everything went in the UI before. > > >> On Mon, 20 May 2019 at 09:57, Tim Mackinnon <tim(a)testit.works> wrote: >> Iâm wondering if others might spot a better way of handling this - but with Exercism, Iâve got 100 exercises to manage. An Exercise is a TestCase and 1 or more solution classes (normally 1, but sometimes several). I had initially used Tags to manage this, there was an ExercismExercise package, and then a tag for each exercise. This was quite neat and tidy - however its flawed as it doesnât allow extension methods on the tags (they live on the parent package - which is problematic as in use, the exercises are loaded one by one from tonel files as the student progresses), it also does let you critique an individual exerciseâ¦ so essentially they arenât sub-projects and I was recommended to promote them to proper Packages. >> >> This was all quite trivial to support with tags but now I have to grapple with the BaselineOf for my project (to manage all these exercises in development mode - where you want to load them all, run all their tests, and add to them etc). >> >> As each exercise depends on an ExercismTestCase - I have a single pre-req for each one, and then, in development mode, I have to load all 100 of them. The best I came up with was the following - but its a hell of a lot more complicated than the previous tag solution where effectively the owning package let me do this once (and membership of that package automatically gave a tag this pre-req and containment behaviour). >> >> So instead I have to do the following (and Iâm left wondering if Iâm missing some easier way). The bold bits are where Iâve tried to do something to try and workaround this - its the array of packageNames that is a bit distasteful to me, and it feels a lot like I have to express the same information twice - one in the iceberg window to add all these packages, and then again in the method of names, to set the identical pre-req on each of themâ¦ I find in this respect, Iâm missing Envy developer here? >> >> Anyone have some better suggestions? Or do we need to try and make the tools better? >> >> Tim >> >> baseline: spec >> <baseline> >> >> spec >> for: #common >> do: [ >> self setUpExercisesFor: spec. >> spec >> package: 'ExercismPharo70'; "Pharo override/patch methods" >> package: 'ExercismTools' >> with: [ spec requires: #('ExercismPharo70') ]; >> >> package: 'ExercismTests' >> with: [ spec requires: #('ExercismTools' 'ExercismMocking'), >> self exerciseTestPackageNames ]; >> >> package: 'ExercismSystemTests' >> with: [ spec requires: #('ExercismTests') ]; >> >> >> package: 'ExercismDev' >> with: [ spec requires: #( >> 'OSProcess' "For shelling out to configlet" >> 'Ring2' "For mentoring support of shadow browsing" >> 'ExercismTools' ), >> self exercisePackageNames, >> #('Exercism' >> >> 'ExercismTests' >> 'ExercismSystemTests')]; >> >> group: 'default' >> with: #('ExercismTools' 'Exercise@Welcome'); >> >> group: 'dev' >> with: #('ExercismDevâ)]. >> >> setUpExercisesFor: spec >> self class exercisePackageNames, self class exerciseTestPackageNames >> do: >> [ :name | spec package: name with: [ spec requires: #('ExercismTools') ] ]. >> >> exercisePackageNames >> "Answer the list of exercise package names (as we don't yet have proper projects)" >> >> ^ #('Exercise@Acronym' 'Exercise@Allergies' 'Exercise@Anagram' 'Exercise@ArmstrongNumbers' 'Exercise@AtbashCipher' 'Exercise@Binary' 'Exercise@Bowling' 'Exercise@Clock' 'Exercise@CollatzConjecture' 'Exercise@Darts' 'Exercise@Diamond' 'Exercise@Die' 'Exercise@Etl' 'Exercise@Forth' 'Exercise@GradeSchool' 'Exercise@Grains' 'Exercise@Hamming' 'Exercise@HelloWorld' 'Exercise@HighScores' 'Exercise@IsbnVerifier' 'Exercise@Isogram' 'Exercise@Leap' 'Exercise@Luhn' 'Exercise@MatchingBrackets' 'Exercise@Pangram' 'Exercise@Proverb' 'Exercise@Raindrops' 'Exercise@ResistorColorDuo' 'Exercise@ReverseString' 'Exercise@RobotSimulator' 'Exercise@RomanNumerals' 'Exercise@SecretHandshake' 'Exercise@Sieve' 'Exercise@SpaceAge' 'Exercise@SumOfMultiples' 'Exercise@Tournament' 'Exercise@TwelveDays' 'Exercise@TwoFer' 'Exercise@Welcome' 'Exercise@WordCount')

May 20, 2019

Re: [Pharo-users] The baseline complexity of tiny big projects...

by Richard O'Keefe

This is not an answer to your question, but it is an observation by someone who was trying all the exercises. As a user, it was just working. Then suddenly, there was a change. Instead of a new exercise popping up underneath Exercism, it would appear as Exercise@Foobar. No big deal. What *is* a big deal is that the "submit" menu item disappeared, and the only way I have found to submit a solution is - File Out the class - Use the command line to download the exercise - Move the filed out class to the exercise directly - exercism submit Foobar.st I had been quite impressed with how smoothly everything went in the UI before. On Mon, 20 May 2019 at 09:57, Tim Mackinnon <tim(a)testit.works> wrote: > Iâm wondering if others might spot a better way of handling this - but > with Exercism, Iâve got 100 exercises to manage. An Exercise is a TestCase > and 1 or more solution classes (normally 1, but sometimes several). I had > initially used Tags to manage this, there was an ExercismExercise package, > and then a tag for each exercise. This was quite neat and tidy - however > its flawed as it doesnât allow extension methods on the tags (they live on > the parent package - which is problematic as in use, the exercises are > loaded one by one from tonel files as the student progresses), it also does > let you critique an individual exerciseâ¦ so essentially they arenât > sub-projects and I was recommended to promote them to proper Packages. > > This was all quite trivial to support with tags but now I have to grapple > with the BaselineOf for my project (to manage all these exercises in > development mode - where you want to load them all, run all their tests, > and add to them etc). > > As each exercise depends on an ExercismTestCase - I have a single pre-req > for each one, and then, in development mode, I have to load all 100 of > them. The best I came up with was the following - but its a hell of a lot > more complicated than the previous tag solution where effectively the > owning package let me do this once (and membership of that package > automatically gave a tag this pre-req and containment behaviour). > > So instead I have to do the following (and Iâm left wondering if Iâm > missing some easier way). The bold bits are where Iâve tried to do > something to try and workaround this - its the array of packageNames that > is a bit distasteful to me, and it feels a lot like I have to express the > same information twice - one in the iceberg window to add all these > packages, and then again in the method of names, to set the identical > pre-req on each of themâ¦ I find in this respect, Iâm missing Envy developer > here? > > Anyone have some better suggestions? Or do we need to try and make the > tools better? > > Tim > > baseline: spec > <baseline> > spec > for: #common > do: [ > *self setUpExercisesFor: spec.* > spec > package: 'ExercismPharo70'; "Pharo override/patch methods" > package: 'ExercismTools' > with: [ spec requires: #('ExercismPharo70') ]; > package: 'ExercismTests' > with: [ spec requires: #('ExercismTools' 'ExercismMocking'), > self exerciseTestPackageNames ]; > package: 'ExercismSystemTests' > with: [ spec requires: #('ExercismTests') ]; > package: 'ExercismDev' > with: [ spec requires: #( > 'OSProcess' "For shelling out to configlet" > 'Ring2' "For mentoring support of shadow browsing" > 'ExercismTools' ), > *self exercisePackageNames,* > #('Exercism' > > 'ExercismTests' > 'ExercismSystemTests')]; > group: 'default' > with: #('ExercismTools' 'Exercise@Welcome'); > group: 'dev' > with: #('ExercismDevâ)]. > > *setUpExercisesFor*: spec > self class exercisePackageNames, self class exerciseTestPackageNames > do: > [ :name | spec package: name with: [ spec requires: #('ExercismTools') ] ]. > > *exercisePackageNames* > "Answer the list of exercise package names (as we don't yet have proper > projects)" > > ^ #('Exercise@Acronym' 'Exercise@Allergies' 'Exercise@Anagram' > 'Exercise@ArmstrongNumbers' 'Exercise@AtbashCipher' 'Exercise@Binary' > 'Exercise@Bowling' 'Exercise@Clock' 'Exercise@CollatzConjecture' > 'Exercise@Darts' 'Exercise@Diamond' 'Exercise@Die' 'Exercise@Etl' > 'Exercise@Forth' 'Exercise@GradeSchool' 'Exercise@Grains' > 'Exercise@Hamming' 'Exercise@HelloWorld' 'Exercise@HighScores' > 'Exercise@IsbnVerifier' 'Exercise@Isogram' 'Exercise@Leap' 'Exercise@Luhn' > 'Exercise@MatchingBrackets' 'Exercise@Pangram' 'Exercise@Proverb' > 'Exercise@Raindrops' 'Exercise@ResistorColorDuo' 'Exercise@ReverseString' > 'Exercise@RobotSimulator' 'Exercise@RomanNumerals' > 'Exercise@SecretHandshake' 'Exercise@Sieve' 'Exercise@SpaceAge' > 'Exercise@SumOfMultiples' 'Exercise@Tournament' 'Exercise@TwelveDays' > 'Exercise@TwoFer' 'Exercise@Welcome' 'Exercise@WordCount') > >

May 20, 2019

The baseline complexity of tiny big projects...

by Tim Mackinnon

Iâm wondering if others might spot a better way of handling this - but with Exercism, Iâve got 100 exercises to manage. An Exercise is a TestCase and 1 or more solution classes (normally 1, but sometimes several). I had initially used Tags to manage this, there was an ExercismExercise package, and then a tag for each exercise. This was quite neat and tidy - however its flawed as it doesnât allow extension methods on the tags (they live on the parent package - which is problematic as in use, the exercises are loaded one by one from tonel files as the student progresses), it also does let you critique an individual exerciseâ¦ so essentially they arenât sub-projects and I was recommended to promote them to proper Packages. This was all quite trivial to support with tags but now I have to grapple with the BaselineOf for my project (to manage all these exercises in development mode - where you want to load them all, run all their tests, and add to them etc). As each exercise depends on an ExercismTestCase - I have a single pre-req for each one, and then, in development mode, I have to load all 100 of them. The best I came up with was the following - but its a hell of a lot more complicated than the previous tag solution where effectively the owning package let me do this once (and membership of that package automatically gave a tag this pre-req and containment behaviour). So instead I have to do the following (and Iâm left wondering if Iâm missing some easier way). The bold bits are where Iâve tried to do something to try and workaround this - its the array of packageNames that is a bit distasteful to me, and it feels a lot like I have to express the same information twice - one in the iceberg window to add all these packages, and then again in the method of names, to set the identical pre-req on each of themâ¦ I find in this respect, Iâm missing Envy developer here? Anyone have some better suggestions? Or do we need to try and make the tools better? Tim baseline: spec <baseline> spec for: #common do: [ self setUpExercisesFor: spec. spec package: 'ExercismPharo70'; "Pharo override/patch methods" package: 'ExercismTools' with: [ spec requires: #('ExercismPharo70') ]; package: 'ExercismTests' with: [ spec requires: #('ExercismTools' 'ExercismMocking'), self exerciseTestPackageNames ]; package: 'ExercismSystemTests' with: [ spec requires: #('ExercismTests') ]; package: 'ExercismDev' with: [ spec requires: #( 'OSProcess' "For shelling out to configlet" 'Ring2' "For mentoring support of shadow browsing" 'ExercismTools' ), self exercisePackageNames, #('Exercism' 'ExercismTests' 'ExercismSystemTests')]; group: 'default' with: #('ExercismTools' 'Exercise@Welcome'); group: 'dev' with: #('ExercismDevâ)]. setUpExercisesFor: spec self class exercisePackageNames, self class exerciseTestPackageNames do: [ :name | spec package: name with: [ spec requires: #('ExercismTools') ] ]. exercisePackageNames "Answer the list of exercise package names (as we don't yet have proper projects)" ^ #('Exercise@Acronym' 'Exercise@Allergies' 'Exercise@Anagram' 'Exercise@ArmstrongNumbers' 'Exercise@AtbashCipher' 'Exercise@Binary' 'Exercise@Bowling' 'Exercise@Clock' 'Exercise@CollatzConjecture' 'Exercise@Darts' 'Exercise@Diamond' 'Exercise@Die' 'Exercise@Etl' 'Exercise@Forth' 'Exercise@GradeSchool' 'Exercise@Grains' 'Exercise@Hamming' 'Exercise@HelloWorld' 'Exercise@HighScores' 'Exercise@IsbnVerifier' 'Exercise@Isogram' 'Exercise@Leap' 'Exercise@Luhn' 'Exercise@MatchingBrackets' 'Exercise@Pangram' 'Exercise@Proverb' 'Exercise@Raindrops' 'Exercise@ResistorColorDuo' 'Exercise@ReverseString' 'Exercise@RobotSimulator' 'Exercise@RomanNumerals' 'Exercise@SecretHandshake' 'Exercise@Sieve' 'Exercise@SpaceAge' 'Exercise@SumOfMultiples' 'Exercise@Tournament' 'Exercise@TwelveDays' 'Exercise@TwoFer' 'Exercise@Welcome' 'Exercise@WordCount')

May 19, 2019

How to visit over packages, classes, methods (all types)

by Tim Mackinnon

Hi - is there a way to iterate over all the code in a package (or class or baseline) in a generic way (to pretty print out class definitions, and methods - including extensions ). I was kind of hoping that with TonelWriter and Fileout and Critics that we would have a generic visitor mechanism but it seems that all of them just implemented it again - which misses a big opportunity for refactoring so that when you want to reason/print/manipulate code - it would be more straight forward. Is there anything/anyone addressing this ? Or maybe Iâve missed an obvious trick somewhere? Tim Sent from my iPhone

May 19, 2019

unable to parse "JOIN" clause with PetitSQLiteGrammar

by matteob8

Good evening, I'm working with "PetitSQLParser" on Pharo 7.0.3 and I've some trouble parsing a "JOIN" query using the class "PetitSQLiteGrammar". More specifically the code is: |identSQL| identSQL:=PetitSQLiteGrammar new. identSQL parse: 'SELECT Code FROM Code_year INNER JOIN Open USING(Code)' ----> "a PP2Failure: 'end of input expected'" Removing "(ECR)" the string get parsed in this way: |identSQL| identSQL:=PetitSQLiteGrammar new. identSQL parse: 'SELECT Code FROM Code_year INNER JOIN Open USING' ----> "an Array(an Array(nil nil an Array(an Array(an Array('SELECT' nil #(#('Code ' nil)) an Array('FROM' an Array(#(#(nil 'Code_year') nil nil) an OrderedCollection(#(#(nil 'INNER' 'JOIN') #(#(nil 'Open') #(nil 'USING') nil) nil)))) nil nil)) nil nil)))" Where is the problem with the first code? Why does the second code get parsed, instead of throwing an error? Is it correct to get all these "nil" objects? Have anyone some suggestion about where I could find information on this issue? Thanks, Matteo -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 18, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by Hilaire

Thanks for the update. Hilaire -- Dr. Geo http://drgeo.eu

May 18, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by Herby VojÄÃk

On 15. 5. 2019 15:44, TomaÅ¾ Turk wrote: > In javascript I believe is > > var f = function(x) { return Math.cos(x) + x; } > var df = function(x) { return f(x + 1e-8) - f(x) * 1e8; } You should use modern JS for comparision, though, so: const f = x => Math.cos(x) + x; const df = x => (f(x + 1e-8) - f(x)) * 1e8; (fixed the operator precedence as well) Herby P.S.: I would parametrize the epsilon, as well as function, so const deriv = epsilon => f => x => (f(x + epsilon) - f(x)) * epsilon; const df = deriv(1e8)(f); > > Best wishes, > Tomaz > > ------ Original Message ------ > From: "Atharva Khare" <khareatharva(a)gmail.com > <mailto:khareatharva@gmail.com>> > To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org > <mailto:pharo-users@lists.pharo.org>> > Sent: 15.5.2019 15:26:11 > Subject: Re: [Pharo-users] Bloc of code in tiers programming language > >> Hey, >> >> I think in python, you use Lambda Expressions. Here is how I would do >> it in python3: >> import math >> f = lambda x: math.cos(x) + x >> d_f = lambda x: (f(x + 1e-8) - f(x)) * 1e8 >> >> >> >> On Wed, May 15, 2019 at 6:33 PM Hilaire <hilaire(a)drgeo.eu >> <mailto:hilaire@drgeo.eu>> wrote: >> >> Hi, >> >> We, Smalltalkers, use bloc of code as easily as we breathe air. >> >> I am writing an article on Smalltalk programming for a French >> mathematics teachers magazine. >> >> To illustrate the simplicity of Smalltalk, I would like to compare how >> the bloc of code 'f' and 'df' below will be implemented in Javascript >> and Python: >> >> >> f := [ :x | x cos + x ]. >> df := [ :x | (f value: x + 1e-8) - (f value: x) * 1e8]. >> >> Here f is a way to implement a function and df its derivate. >> >> Do some of you knows how it will be written in Javascript and Python >> with their own ad-hoc anonymous function? >> >> Thanks >> >> Hilaire >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >>

May 18, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by Offray Vladimir Luna CÃ¡rdenas

Hi Ted, On 17/05/19 6:38 p.Â m., Brainstorms wrote: > Hi Offray, > > Yes, I definitely agree with you that Lua does not have the nice development > environment of Pharo (what other language does?), and is very bare-bones, as > it was originally intended for embedded applications. Yep, Pharo and other Smalltalk based IDEs are unbeatable as programming experiences. What they have changed in my, is my look for other similar experiences. In fact was going from an interactive first computing experience that I explored things like Squeak, Etoys, Bots Inc, IPython/Jupyter and Pharo. Trying to get something similar in Lua has point me towards Zero Brane Studio (ZBS), which is (like Pharo) a Lua IDE made on Lua itself. > I've gone through > nearly all of the online version of the Pharo MOOC now, and the ease of > building a web app with Pharo+Seaside is /amazing/. (That's reason enough > to adopt Pharo!) I'm now looking at Spec and how to work with that to make > GUI apps. I can't do web apps in Lua, nor is there a GUI in Lua. Spec and making GUI was the way I started my exploration with Pharo. Particularly using the Spec-GT bridge to create interactive notebooks in Grafoscopio. In my case, works better when you have a "real world" example to learn/solve in your programming environment. ZBS is made on Lua using Wx Widgets for Lua, but as you point after, it is an extra library. On the web front I saw some Seaside and Aida Web, but now I'm more into and even more minimalist approach using Teapot. Even I have a pretty alpha stuff combining Teapot with Material Design Light and Fossil at: https://mutabit.com/repos.fossil/brea/ > > For that matter, with Lua there is no interaction with the OS, no sockets, > and very minimal file system interaction (that's actually built into Lua -- > it doesn't even know what a directory is). All of these capabilities can be > had in Lua, but they must be provided by external libraries -- even the > ability to interact via a terminal command line is typically done via a > small C app that wraps a Lua "state". Lua is tiny. Tiny, but powerful. Yes I like this pretty minimal setup for Lua. In fact I found it (again) while working on reproducible research and publishing, as the extension language for Pandoc and LaTeX (via LuaTeX). > > So I see that as an advantage, and a compliment to Pharo. Seaside may be an > external library to Pharo, but much of "the rest" is built-in, and comes > with a nice OS/IDE to wrap it all up and keep things together. Did not > Smalltalk-80 invent the concept of a container, which is becoming all the > rage in IT today? Yet another first for ST..? I remember some talk in Twitter with the Docker people about how Smalltalk was an inspiration of the containers idea, but I can't locate it again. > > So I guess that's my beginner impression of Pharo: a great environment that > lives in a container. (I'm learning how to implement containers and > implement /in/ containers now, too.) How easy is it to cross that boundary > and interact with the rest of the world? Maybe another way Lua and Pharo > are dissimilar? In my case, I interact with the external world via formats and DOMs using parsers for JSON, HTML, CVS and so on and some times callings to the OS. No obstacles there. Pharo is a pretty well suited environment to interact with the external world on data visualization/processing issues for reproducible research and publishing, while it helps me in keep incidental complexity away, being a pretty self contained environment. > > Example: I automate hardware... Can I use Pharo to interact with > instrumentation over USB? Yes. There is a Pharo things project and Phratch (Arduido + Pharo + Scratch) which use Pharo to interact with hardware. Cheers, Offray

May 18, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by Brainstorms

Hi Offray, Yes, I definitely agree with you that Lua does not have the nice development environment of Pharo (what other language does?), and is very bare-bones, as it was originally intended for embedded applications. I've gone through nearly all of the online version of the Pharo MOOC now, and the ease of building a web app with Pharo+Seaside is /amazing/. (That's reason enough to adopt Pharo!) I'm now looking at Spec and how to work with that to make GUI apps. I can't do web apps in Lua, nor is there a GUI in Lua. For that matter, with Lua there is no interaction with the OS, no sockets, and very minimal file system interaction (that's actually built into Lua -- it doesn't even know what a directory is). All of these capabilities can be had in Lua, but they must be provided by external libraries -- even the ability to interact via a terminal command line is typically done via a small C app that wraps a Lua "state". Lua is tiny. Tiny, but powerful. So I see that as an advantage, and a compliment to Pharo. Seaside may be an external library to Pharo, but much of "the rest" is built-in, and comes with a nice OS/IDE to wrap it all up and keep things together. Did not Smalltalk-80 invent the concept of a container, which is becoming all the rage in IT today? Yet another first for ST..? So I guess that's my beginner impression of Pharo: a great environment that lives in a container. (I'm learning how to implement containers and implement /in/ containers now, too.) How easy is it to cross that boundary and interact with the rest of the world? Maybe another way Lua and Pharo are dissimilar? Example: I automate hardware... Can I use Pharo to interact with instrumentation over USB? -Ted Offray Vladimir Luna CÃ¡rdenas-2 wrote > Hi t, > > Yes, I know that Lua support OOP, with several implementations and using > metatables. I have not looked in detail. But the idea of shared > similarities while being at opposite extremes of the programming > spectrum/experience is more related with both sharing minimalist > concepts applied everywhere (objects and messages for Pharo, tables and > functions for Lua), but one provided a full IDE/GUI and being tied with > a programming paradigm, which makes it great for agile prototyping, > while the other offers just the bare minimum and you arm your puzzle > from there regarding tools, paradigms, which makes it great for embedding. > > Cheers, > > Offray -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 17, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by Offray Vladimir Luna CÃ¡rdenas

Hi t, Yes, I know that Lua support OOP, with several implementations and using metatables. I have not looked in detail. But the idea of shared similarities while being at opposite extremes of the programming spectrum/experience is more related with both sharing minimalist concepts applied everywhere (objects and messages for Pharo, tables and functions for Lua), but one provided a full IDE/GUI and being tied with a programming paradigm, which makes it great for agile prototyping, while the other offers just the bare minimum and you arm your puzzle from there regarding tools, paradigms, which makes it great for embedding. Cheers, Offray On 17/05/19 3:29 p.Â m., Brainstorms wrote: > Hi Offray, > > You probably know that you can develop Lua using OOP techniques, so they're > not so opposite for me, at least. There is a significant difference as far > as their OOP styles, however: Lua OOP is prototype-based, not class-based. > > But you can fashion class(like) objects in Lua and program as though classes > existed -- albeit with some quirks taken into account (beyond the obvious > message-vs-function call difference). The important thing is that you can > enjoy the benefits of using OO design patterns with Lua. > > Lua has dynamic typing, every data type is first-class, it has a nil value, > inheritance (via metatables), closures, coroutines, limited reflection > (which you could possibly enhance through its C interface), and a nice C API > for gluing other code/languages together. Much of its functionality is > obtained through included external libraries (most of which are written in > C). > > What I hope to see is a nice FFI for Pharo that allows connection to Lua > code. With that, I can glue Pharo to anything... We've been using it to > automate LabVIEW applications. I want to automate LabVIEW with Pharo as > well. > > -t > > > Offray Vladimir Luna CÃ¡rdenas-2 wrote >> Is nice to see this similitude between Lua and Pharo. We have been using >> both in the Grafoscopio[1] project, because Lua is Pandoc's default >> choice for embedded scripting language, and is pretty fast on the >> Abstract Syntax Tree filters. >> >> [1] https://mutabit.com/grafoscopio/index.en.html >> >> For me Lua and Pharo are kind on opposite sides of the programming >> spectrum/experience but is nice to see this conceptual connections. >> Hopefully we, at the local hackerspace, will be able to explore the >> Lua+Pharo bridge more and showcase them here. >> >> Cheers, >> >> Offray > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

May 17, 2019