- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] Re: [vwnc] Does anyone have a "new" string literal?

by stepharong

Hi David Where can we find - motivation - examples - implementation Did you write a report or something that we can read and assess? Tx > I realize this is a few years old but I wanted to give an update on my > quest > for quasi-literals. I did a complete quasi-literal framework for Java > when > I moved over to Oracle Labs. It used the annotation compiler + a few > tweeks > to the scanner and parser. You could extend the name space of the > quasi-literal and have inline SQL or APL. All the parsing, validation, > and > code rewriting happened at compile time. We proposed it to the Java > Product > guys and got ignored to death. > > As to the characters I did backquote for simple quasi-literal Strings and > used Oxford Brackets for the quasi-literals with a language namespace. <| > ...|>. Back quote can be hard to see but is nice for String substitute. > > At this point in time the language that does it most right is JavaScript. > Thanks Mark Miller for all the hard work over the years! > > > > > -- > View this message in context: > http://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp46670… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 28, 2017

Re: [Pharo-dev] [squeak-dev] Re: [vwnc] Does anyone have a "new" string literal?

by stepharong

Hi david What you describe is a bit scary. Because this is just changing the syntax but it is probably also breaking refactorings and probably other. May I ask why would we need macros since after more than 30 years nobody really need them. So do you have good motivating cases for quasi quotes Opal supports compile time evaluation. Stef > The ES6 design is sound and if you are in a hurry to get the capability > it > is a great way to go. Once you start using it and get a taste for > quasi-literal little languages you will find that you want more. > > Having a quasi-literal that let's you name the little language to parse > you > open a very interesting door. After the dust settles you need a parser > and > compiler framework that allows plugins at every stage. You "MUST" have a > rich and stable AST and it must be usable as a quasi-literal because > transpilers abound. You wind up with transpiler code that is templated > and > quite "Lispy". > > At the end of the day you will finally let in Macros. I believe thatJulia > got all this right. They stick a "@" in front of their macro invocations > so > you get rid of a lot of confusion. David Moon made the Julia macro > system a > thing of true beauty. Perfection actually. > > At the end of the day you want Smalltalk Compile Time "Staged Meta > Evaluation". > > Still, at a minimum go with the ES6 design. Consider "<|" because " ` " > is > hard to see. Some fonts do a terrible job with it. You could do both. > > > > > -- > View this message in context: > http://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp46670… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 28, 2017

Re: [Pharo-dev] [squeak-dev] Re: [vwnc] Does anyone have a "new" string literal?

by DavidLeibs

The ES6 design is sound and if you are in a hurry to get the capability it is a great way to go. Once you start using it and get a taste for quasi-literal little languages you will find that you want more. Having a quasi-literal that let's you name the little language to parse you open a very interesting door. After the dust settles you need a parser and compiler framework that allows plugins at every stage. You "MUST" have a rich and stable AST and it must be usable as a quasi-literal because transpilers abound. You wind up with transpiler code that is templated and quite "Lispy". At the end of the day you will finally let in Macros. I believe thatJulia got all this right. They stick a "@" in front of their macro invocations so you get rid of a lot of confusion. David Moon made the Julia macro system a thing of true beauty. Perfection actually. At the end of the day you want Smalltalk Compile Time "Staged Meta Evaluation". Still, at a minimum go with the ES6 design. Consider "<|" because " ` " is hard to see. Some fonts do a terrible job with it. You could do both. -- View this message in context: http://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp46670… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 28, 2017

Re: [Pharo-dev] REMEMBER: Tomorrow 28/02 16h UTC TechTalk: Reflectivity

by Peter Uhnak

This site should be automatically time-zone aware https://a.chronus.eu/17A7E60 On Tue, Feb 28, 2017 at 10:50:41PM +0800, Ben Coman wrote: > Can we have a link and a countdown? > cheers -ben > > On Mon, Feb 27, 2017 at 10:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > Hi, > > > > It will be handled by Marcus who will present current status of > > Reflectivity integration. > > > > Esteban > > > > > >

Feb. 28, 2017

Pharo TechTalk starting in one hour (16UTC) (LINKS)

by Esteban Lorenzano

Hi, So, techtalk will be here: https://www.youtube.com/watch?v=H52MAu_ISgU <https://www.youtube.com/watch?v=H52MAu_ISgU> and discussion channel will be through discord, as always, here: http://discord.gg/Sj2rhxn <http://discord.gg/Sj2rhxn> See you there! Esteban

Feb. 28, 2017

Re: [Pharo-dev] REMEMBER: Tomorrow 28/02 16h UTC TechTalk: Reflectivity

by Ben Coman

Can we have a link and a countdown? cheers -ben On Mon, Feb 27, 2017 at 10:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > It will be handled by Marcus who will present current status of > Reflectivity integration. > > Esteban > > >

Feb. 28, 2017

[pharo-project/pharo-core] 4e8d88: 60417

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 4e8d884ef5ef34a144070b758d44988be1e3f468 https://github.com/pharo-project/pharo-core/commit/4e8d884ef5ef34a144070b75… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-28 (Tue, 28 Feb 2017) Changed paths: M OpalCompiler-Core.package/OCAbstractMethodScope.class/instance/lookup/lookupVar_inContext_.st A OpalCompiler-Core.package/OCBlockScope.class/instance/lookup/nextOuterScopeContextOf_.st M OpalCompiler-Core.package/OCBlockScope.class/instance/lookup/outerScopeLookupVar_inContext_.st A OpalCompiler-Core.package/OCOptimizedBlockScope.class/instance/lookup/nextOuterScopeContextOf_.st A OpalCompiler-Tests.package/OCContextTempMappingTest.class/instance/tests/fetchArgFromOptimizedBlockInsideFullBlock_extraArg_.st A OpalCompiler-Tests.package/OCContextTempMappingTest.class/instance/tests/testAccessingArgOfOuterBlockFromAnotherDeepBlock.st A OpalCompiler-Tests.package/OCContextTempMappingTest.class/instance/tests/testAccessingMethodArgFromOptimizedBlockContext.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60416.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60417.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60416.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60417.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M UnifiedFFI-Tests.package/FFIExternalStructurePlatformTests.class/instance/tests/testStructureHasCorrectOffsets32bits.st M UnifiedFFI-Tests.package/FFIExternalStructurePlatformTests.class/instance/tests/testStructureHasCorrectOffsets64bits.st Log Message: ----------- 60417 19770 FFIExternalStructurePlatformTests>>#testStructureHasCorrectOffsets32bits is failing on the bootstrapped image https://pharo.fogbugz.com/f/cases/19770 19761 Debugger wrong temp var value after multiple step through block https://pharo.fogbugz.com/f/cases/19761 http://files.pharo.org/image/60/60417.zip

Feb. 28, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60417 Home: https://github.com/pharo-project/pharo-core

Feb. 28, 2017

Re: [Pharo-dev] How to listen for microsoft os windows messages (WM_MESSAGE's)?

by Dimitris Chloupis

The first thing is to be very precise in what you want. I thought you wanted a window manager now you mention a full blow GUI API. Frankly if you want to ovehaul Pharo GUI API , personally I think hands down a Pharo QT project will be far more valuable. Windows may have an overwhelming market of 90% of OS users but the same is not true for developers. Developers are far more attracted to other platforms like MacOS and Linux. MacOS especially has a very loyal and quite large developer crowd. So a WIN API solution will not be as attractive as cross platform QT. QT not only work on Win, Mac and Linux , it also work inside Web pages , iOS and Android. If we take into account that mobile is the most rapidly growing market you can imagine why QT is so much loved by devs. I also recommend to get your hands dirty and learn C. Yes there are easier solutions out there, much easier, but knowing C does not open a door it opens a multiverse of possibilities. Its a huge bonus to have in your coding arsenal. C and C++ may not be as loved as Pharo but its a necessary evil none the less. There is also the .NET options which provided the native gui on widnows and recently it open sourced and gained support from Microsoft for other platforms. Basically M$ bought Xamarin , the company responsible for MONO , a .NET that can run on pretty much any platform with support for C#, Python, Delphi, J#, F# and many other langauges. But personally I do not trust Microsoft. In any case using an existing GUI API will make your life eaiser. Both QT and Winforms (.NET GUI API) are very well designed but Win API (especially MFC) are a monstrosity. Another solution is to get your hands dirty and help with Bloc, the new replacement for Morphic which is the standard Pharo GUI API. I am sure Bloc devs would love your assistance and Bloc already works well so it will be eaiser for you too. You can instead focus on features you care the most and bring those features inside Bloc or as a separate Pharo library depending on Bloc. This will be extremely valuable for your Pharo user because we will be moving to Bloc slowly next year and thus they wont have to learn a new GUI API. Hence why I said that you need to define a precise strategy. Pitch your ideas , discuss them here, see if there devs already working on similar features. You will be surprised how much "buried" Pharo code there is out there. People make it for personal use and never both to advertise it or even mention it. Coders are generally terrible at 3 things 1) GUIs 2) Code design 3) Promotion On Tue, Feb 28, 2017 at 3:17 PM lw1990 <lukewallace1990(a)gmail.com> wrote: > Thank you all for the excellent replies > I will be rereading them, here are my thoughts/responses for now: > > There exists a windows scripting language called autohotkey > (autohotkey.com) similar to autoit, which does everything I want, I > merely > wanted to make similar functionality in Pharo so I could use Pharo - it > will > be better for large and ambitious windows projects. > > AutoHotkey is open source and the source of the language is in C. > > So, most or all of the necessary C code is hopefully already available, I > will just have to figure out how to put it into Pharo. It will not be as > ambitious as Autohotkey itself because Pharo has most of the functionality > required by default - all that is needed is DllCall's for the Windows API > to > get/set values, hooks to be aware of Windows Messages, and perhaps one day > an API to create native windows gui's using Pharo syntax. That is at least > all of the main stuff I can think of that would be useful to most business > people that want to automate their windows OS. > > Pharo offers a very good IDE/debugger and programming environment, and > natural language syntax which Autohotkey lacks. Autohotkey is the best > there > is right now, but I believe Pharo could surpass it quickly once some of > this > functionality is implemented. The number one reason Autohotkey is easy to > use is because the community is extremely responsive and helpful, and Pharo > seems to be this way too :-) > > > > -- > View this message in context: > http://forum.world.st/How-to-listen-for-microsoft-os-windows-messages-WM-ME… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Feb. 28, 2017

Re: [Pharo-dev] How to listen for microsoft os windows messages (WM_MESSAGE's)?

by lw1990

Thank you all for the excellent replies I will be rereading them, here are my thoughts/responses for now: There exists a windows scripting language called autohotkey (autohotkey.com) similar to autoit, which does everything I want, I merely wanted to make similar functionality in Pharo so I could use Pharo - it will be better for large and ambitious windows projects. AutoHotkey is open source and the source of the language is in C. So, most or all of the necessary C code is hopefully already available, I will just have to figure out how to put it into Pharo. It will not be as ambitious as Autohotkey itself because Pharo has most of the functionality required by default - all that is needed is DllCall's for the Windows API to get/set values, hooks to be aware of Windows Messages, and perhaps one day an API to create native windows gui's using Pharo syntax. That is at least all of the main stuff I can think of that would be useful to most business people that want to automate their windows OS. Pharo offers a very good IDE/debugger and programming environment, and natural language syntax which Autohotkey lacks. Autohotkey is the best there is right now, but I believe Pharo could surpass it quickly once some of this functionality is implemented. The number one reason Autohotkey is easy to use is because the community is extremely responsive and helpful, and Pharo seems to be this way too :-) -- View this message in context: http://forum.world.st/How-to-listen-for-microsoft-os-windows-messages-WM-ME… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 28, 2017