July 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Problems with PunQLite

by Esteban Lorenzano

Hi, while the installer should download and install the dll, I have seen that in some cases it does not downloads it correctly. can you try to download the library from here: https://github.com/pharo-nosql/PunQLite/releases/tag/stable <https://github.com/pharo-nosql/PunQLite/releases/tag/stable> and putting it in same dir as your image? (which is where should be the downloaded dll, so you need to replace it). cheers! Esteban > On 12 Jul 2017, at 14:10, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Hello > > Just an update on a further test. Going through old e-mails, I saw Esteban Lorenzanoâs recommendation to use a different repository to install PunQLite. I used his snippet: > Metacello new > repository: 'github://pharo-nosql/PunQLite/repository' <github://pharo-nosql/PunQLite/repository'>; > baseline: 'PunQLite'; > load. > to install it in a clean Moose 6.1 image. The results were the same; all tests red, manual test gave error: âExternal module not foundâ. I suspect it is all a matter of getting the unqlite.dll module where it can be found, but I donât know where this should be. > > Thanks for any help > > Peter Kenny > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of PBKResearch > Sent: 11 July 2017 18:27 > To: pharo-users(a)lists.pharo.org > Subject: [Pharo-users] Problems with PunQLite > > Hello > > I have decided to have another try with PunQLite, having failed to get it working before. For the record, I am using Windows 10 Home with all recent updates applied. > > I tried the following: > > Download latest image of Moose 6.1 (Pharo 6.0 Latest update: #60507). > Search Catalog Browser for PunQLite, which is flagged as OK for Pharo 6.0, and select âInstall stable versionâ. > Check that the file unqlite.dll has been installed in the same folder as the image. > Run tests in PqDatabaseTests. 30 tests run, all red. > Try to run some tests manually. Enter âPqDatabase openOnMemoryâ and âdoItâ. Result: âError: External module not foundâ. > > Looking at the Monticello Browser, I see that my image has ConfigurationOfPunQLite(TorstenBergmann.29) and PunQLite-Core(TorstenBergmann.28). This is the version chosen as stable by the Catalog Browser. Have I in fact got the right version? Do I have to do something with the .dll to make it visible to the .ffi call? > > Any suggestions gratefully received. > > Peter Kenny

July 12, 2017

Re: [Pharo-users] Problems with PunQLite

by PBKResearch

Hello Just an update on a further test. Going through old e-mails, I saw Esteban Lorenzano's recommendation to use a different repository to install PunQLite. I used his snippet: Metacello new repository: 'github://pharo-nosql/PunQLite/repository'; baseline: 'PunQLite'; load. to install it in a clean Moose 6.1 image. The results were the same; all tests red, manual test gave error: 'External module not found'. I suspect it is all a matter of getting the unqlite.dll module where it can be found, but I don't know where this should be. Thanks for any help Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of PBKResearch Sent: 11 July 2017 18:27 To: pharo-users(a)lists.pharo.org Subject: [Pharo-users] Problems with PunQLite Hello I have decided to have another try with PunQLite, having failed to get it working before. For the record, I am using Windows 10 Home with all recent updates applied. I tried the following: 1. Download latest image of Moose 6.1 (Pharo 6.0 Latest update: #60507). 2. Search Catalog Browser for PunQLite, which is flagged as OK for Pharo 6.0, and select 'Install stable version'. 3. Check that the file unqlite.dll has been installed in the same folder as the image. 4. Run tests in PqDatabaseTests. 30 tests run, all red. 5. Try to run some tests manually. Enter 'PqDatabase openOnMemory' and 'doIt'. Result: 'Error: External module not found'. Looking at the Monticello Browser, I see that my image has ConfigurationOfPunQLite(TorstenBergmann.29) and PunQLite-Core(TorstenBergmann.28). This is the version chosen as stable by the Catalog Browser. Have I in fact got the right version? Do I have to do something with the .dll to make it visible to the .ffi call? Any suggestions gratefully received. Peter Kenny

July 12, 2017

Fwd: [CfP][Meta'17] Workshop on Meta-Programming Techniques and Reflection

by Guillermo Polito

Hi all, sorry for multiple copies, ========================================================= Call for Papers: Metaâ17 ======================== Workshop on Meta-Programming Techniques and Reflection Co-located with SPLASH 2017 October 22, 2017, Vancouver, Canada Twitter @MetaAtSPLASH http://2017.splashcon.org/track/meta-2017 The heterogeneity of mobile computing, cloud applications, multicore architectures, and other systems leads to increasing complexity of software and requires new approaches to programming languages and software engineering tools. To manage the complexity, we require generic solutions that can be adapted to specific application domains or use cases, making metaprogramming an important topic of research once more. However, the challenges with metaprogramming are still manifold. They start with fundamental issues such as typing of reflective programs, continue with practical concerns such as performance and tooling, and reach into the empirical field to understand how metaprogramming is used and how it affects software maintainability. Thus, while industry accepted metaprogramming on a wide scale with Ruby, Scala, JavaScript and others, academia still needs to answer a wide range of questions to bring it to the same level of convenience, tooling, and programming styles to cope with the increasing complexity of software systems. This workshop aims to explore meta-level technologies that help tackling the heterogeneity, scalability and openness requirements of emerging computations platforms. ### Topics of Interest The workshop is a venue for all approaches that embrace metaprogramming: - from static to dynamic techniques - reflection, meta-level architectures, staging, open language runtimes applications to middleware, frameworks, and DSLs - optimization techniques to minimize runtime overhead - contract systems, or typing of reflective programs reflection and metaobject protocols to enable tooling - case studies and evaluation of such techniques, e.g., to build applications, language extensions, or tools - empirical evaluation of metaprogramming solutions - security in reflective systems and capability-based designs - meta-level architectures and reflective middleware for modern runtime platforms (e.g. IoT, cyber-physical systems, mobile/cloud/grid computing, etc) - surveys, conceptualization, and taxonomization of existing approaches In short, we invite contributions to the workshop on a wide range of topics related to design, implementation, and application of reflective APIs and meta-programming techniques, as well as empirical studies and typing for such systems and languages. ### Workshop Format and Submissions This workshop welcomes the presentation of new ideas and emerging problems as well as mature work as part of a mini-conference format. Furthermore, we plan interactive brainstorming and demonstration sessions between the formal presentations to enable an active exchange of ideas. The workshop papers will be published in the ACM DL, if not requested otherwise by the authors. Thus, they will be part of SPLASH workshop proceedings. Therefore, papers are to be submitted using the SIGPLAN acmart style: http://www.sigplan.org/Resources/Author/. Please use the provided double-column templates for Latex http://www.sigplan.org/sites/default/files/acmart/current/ acmart-sigplanproc-template.tex) or Word http://www.acm.org/publications/proceedings-template. - technical paper: max. 8 pages, excluding references - position and work-in-progress paper: 1-4 pages, excluding references - technology demos or a posters: 1-page abstract Demos, posters, position and work-in-progress papers can be submitted on a second, later deadline to discuss the latest results and current work. For the submission, please use the submission system at: https://meta17.hotcrp.com/ ### Important Dates Abstract Submission: 07 August 2017 Paper Submission: 14 August 2017 Author Notification: 06 September 2017 Position/WIP Paper Deadline: 08 September 2017 Camera Ready Deadline: 18 September 2017 Position/WIP Notification: 21 September 2017 ### Program Committee The program committee consists of the organizers and the following reviewers: Anya Helen Bagge, University of Bergen, Norway Daniele Bonetta, Oracle Labs, Austria Nicolas Cardozo, Universidad de los Andes, Colombia Sebastian Erdweg, TU Delf, The Nederlands Robert Hirschfeld, HPI, Germany Roberto Ierusalimschy, PUC-Rio, Brazil Pablo Inostroza, CWI, The Nederlands Kim Mens, Universite Catholique de Louvain, Belgium Cyrus Omar, Carnegie Mellon University, USA Guillermo Polito, CNRS, France Tiark Rompf, Purdue University, USA Tom Van Cutsem, Nokia Bell Labs, Belgium Takuo Watanabe, Tokyo Institute of Technology, Japan ### Workshop Organizers Shigeru Chiba, University of Tokyo Elisa Gonzalez Boix, Vrije Universiteit Brussel Stefan Marr, Johannes Kepler University Linz ### Contact information For further inquires, do not hesitate to contact the organizers via meta AT soft.vub.ac.be http://2017.splashcon.org/track/meta-2017 -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

July 12, 2017

Re: [Pharo-users] Using the Debugger to write code

by Marcus Denker

> On 12 Jul 2017, at 10:51, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 12 Jul 2017, at 10:46, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> >> 2017-07-12 9:09 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: >> in the workspace it creates a variable (with value nil)â¦ so it treats upper-case >> unknown vars the same as lower case. >> >> I think it might make sense to have for upper case instead the menu that asks >> what to do (it could there have a âadd binding to workspaceâ entry for the current >> way, too) >> >> I would prefer same behaviour like in method editor. I really hate when I made mistake in class name and after evaluation I got uppercase binding with nil value. > > yes, we should fix it. binding should just be created for lower case vars. > How to fix it: OCRequestorScope is the scope of variables in tools. #lookupVar: is the method that is doing the lookup. replace the code global := self lookupGlobalVar: name. global ifNotNil: [ ^ global ]. with: name first isUppercase ifTrue: [ ^ outerScope lookupVar: name]. But: right now we abuse the requesterscope to implement the feature that you can hand in an additional dictionary with bindings. See testEvaluateWithBindingsWithUppercaseName This change breaks this featureâ¦ but it just means we need to implement this better, which I will do . Marcus

July 12, 2017

Re: [Pharo-users] Using the Debugger to write code

by Marcus Denker

> On 12 Jul 2017, at 10:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-07-12 9:09 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > in the workspace it creates a variable (with value nil)â¦ so it treats upper-case > unknown vars the same as lower case. > > I think it might make sense to have for upper case instead the menu that asks > what to do (it could there have a âadd binding to workspaceâ entry for the current > way, too) > > I would prefer same behaviour like in method editor. I really hate when I made mistake in class name and after evaluation I got uppercase binding with nil value. yes, we should fix it. binding should just be created for lower case vars. Marcus

July 12, 2017

Re: [Pharo-users] Using the Debugger to write code

by Denis Kudriashov

2017-07-12 9:09 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > in the workspace it creates a variable (with value nil)â¦ so it treats > upper-case > unknown vars the same as lower case. > > I think it might make sense to have for upper case instead the menu that > asks > what to do (it could there have a âadd binding to workspaceâ entry for the > current > way, too) > I would prefer same behaviour like in method editor. I really hate when I made mistake in class name and after evaluation I got uppercase binding with nil value.

July 12, 2017

Re: [Pharo-users] Using the Debugger to write code

by K K Subbu

On Wednesday 12 July 2017 01:36 PM, Marcus Denker wrote: > The compiler knows two modes: > âInteractiveâ and not. So if there is a undeclared var, it will in interactive > mode ask the user what to do, but when compiling non-interactively it > will just add the var to Undeclared (with a nil value) and compile a binding > to that. If I run Motivation fromString: 'loo' from Playground or Inspector, I get a DNU window for #fromString not a prompt for defining this variable. Shouldn't Playground/Inspector be considered interactive? Why is Motivation assumed undeclared? Curious .. Subbu

July 12, 2017

Re: [Pharo-users] Using the Debugger to write code

by Marcus Denker

> On 12 Jul 2017, at 09:09, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 12 Jul 2017, at 08:54, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Yes, but these are all inside the method editor. >> >> I wanted to start with >> >> (Motivation fromString: 'foo') sayIt. >> >> in a playground/workspace. > > in the workspace it creates a variable (with value nil)â¦ so it treats upper-case > unknown vars the same as lower case. > > I think it might make sense to have for upper case instead the menu that asks > what to do (it could there have a âadd binding to workspaceâ entry for the current > way, too) > for the #asClass case it is more complex. The compiler knows two modes: âInteractiveâ and not. So if there is a undeclared var, it will in interactive mode ask the user what to do, but when compiling non-interactively it will just add the var to Undeclared (with a nil value) and compile a binding to that. Now #asClass happens not at compile-time, but at runtime. The compiler can not do anything (itâs just a message send), and at runtime we do *not* model âinteractive useâ vs. not. Now if you look at Denis enhancement of the test execution, there is now CurrentExecutionEnvironment value which allows us at runtime to check if we run a test (and which). Now we could extend that and model âinteractive useâ vs. ânon-interactiveâ in addition. Then code like #asClass could ask the user in interactive mode to create a non-existing class. But the question is if we would want thatâ¦ (I like the idea of modelling interactive vs. not using the execution environment, though). Marcus

July 12, 2017

Re: [Pharo-users] Using the Debugger to write code

by Marcus Denker

> On 12 Jul 2017, at 08:54, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Yes, but these are all inside the method editor. > > I wanted to start with > > (Motivation fromString: 'foo') sayIt. > > in a playground/workspace. in the workspace it creates a variable (with value nil)â¦ so it treats upper-case unknown vars the same as lower case. I think it might make sense to have for upper case instead the menu that asks what to do (it could there have a âadd binding to workspaceâ entry for the current way, too) Marcus

July 12, 2017

Re: [Pharo-users] Using the Debugger to write code

by phil＠highoctane.be

(#Motivation asClass fromString: 'a') sayIt is not working better :-) Should. Phil On Wed, Jul 12, 2017 at 8:54 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, but these are all inside the method editor. > > I wanted to start with > > (Motivation fromString: 'foo') sayIt. > > in a playground/workspace. > > But with just a DNU it works. > > > On 12 Jul 2017, at 08:49, phil(a)highoctane.be wrote: > > > > What is not working? Check this: > > > > <image.png> > > > > Hit Define new class and just accept what is proposed, then proceed > > > > <image.png> > > > > Now hit Create and define the method. > > > > <image.png> > > > > etc etc for usual coding. > > > > Best, > > Phil > > > > On Wed, Jul 12, 2017 at 8:35 AM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > > On Wednesday 12 July 2017 08:33 AM, horrido wrote: > > But for the life of me, I can't figure out how to create new classes for > my > > application from within the Debugger. Must I create new classes using the > > System Browser first before I can continue adding new methods from within > > the Debugger? What's the recommended procedure for all this? > > > > Not necessarily. In Pharo, everything happens through message sends. > > Classes are created by sending any one of subclass:* family of messages > to the parent class. System Browser makes it convenient by adding a > template to its bottom text panel. Magic happens in the subclass:* message > sends. > > > > When you "inspect" an object in the Debugger, a text panel will open up > along the right side where you can type in a command just like in System > Browser and "doIt". E.g. to create a subclass from Object. > > > > Object subclass: ... > > > > HTH .. Subbu > > > > > > > > > >

July 12, 2017