April 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #233: 3224-Fix-ProperMethodCategorizationTest-to-not-enforce-running-protocol-
by ci-pharo-ci-jenkins2＠inria.fr April 25, 2019

April 25, 2019

There is a new Pharo build available! The status of the build #233 was: FAILURE. The Pull Request #3227 was integrated: "3224-Fix-ProperMethodCategorizationTest-to-not-enforce-running-protocol-" Pull request url: https://github.com/pharo-project/pharo/pull/3227 Issue Url: https://github.com/pharo-project/pharo/issues/3224 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] [vwnc] most energy efficient AI system - challenge of the German Federal Ministry of Education and Research BMBF
by Bernhard HÃ¶fner April 24, 2019

April 24, 2019

Hello group, Bernard Portier from University Brest allowed me to forward his ideas referring to works of different scientists. It may help to concretize an AI-project or to fertilize discussion. I am not an AI-specialist and sorry not to be able to participate on a discussion. Best Regards, Bernhard â¦ Dear Bernhard, This is a summary of work done at University of Brest for mapping Smalltalk computation to hardware. 1) efficiency is concurrency in execution During decades researchers and industry was running behind the work of Xerox PARC on micro- programmed computers, such as the Dorado. The Dorado implemented a pipeline for decoding languages intermediate code developped for this purpose. Smalltalk bytecodes as delivered for Smalltalk-80 were of this kind. Behind the streaming engine that prepared the execution, there was the micro-machine routines translated by PARC into micro-program control executing several internal operations in parallel. The blue book implementation part is just a description of how the instructions are executed. (For those who do not know about micro-programming, there are primers written in the 70's by Michael Flynn to explain link between the instruction set, micro-program structure, and program execution. It takes 1 day to read, understand, and experiment: look at Ci lines that activate concurrent operations from a micro-code word.) [Flynn] Micro-programming, includes Rosin machine, in Computer Architecture 1972. Annex 1. [Dorado] Retrospective, Pier. http://bitsavers.trailing-edge.com/pdf/xerox/parc/techReports/ISL-83 <http://bitsavers.trailing-edge.com/pdf/xerox/parc/techReports/ISL-83>- 1_A_Retrospective_on_the_Dorado_A_High-Performance_Personal_Computer.pdf So, Smalltalk was fast enough in 1980, it was well understood for a machine execution, and became so slow when executed on micro processors, despite valuable efforts at UCBerkeley, Stanford and others. 2) concurrency is now easily available Probably one could implement Rosin machine in few days, plus a compiler to translate a calculator syntax into instruction set for it. Research could rather examine chances to execute high level computer language at the current level of resources as FPGAs devices and shared memory accelerators. In the second case, one can recall that previous generation of massive parallel computers used Smalltalk to model execution. It was the case for Maspar machine which debugger was showing clearly a ParcPlace support to display assertions on parallel (plural) variables. This debugger inspired some work to support parallel execution on GPU as shown in [VanLong]. [VanLong] Master report. Annex 2. http://wsn.univ-brest.fr/pottier/long.pdf <http://wsn.univ-brest.fr/pottier/long.pdf> (See also https://www.mdpi.com/1424-8220/18/7/2323 <https://www.mdpi.com/1424-8220/18/7/2323> about parallel physical simulation) 3) execution and definition of object spaces can replace types. Smalltalk does not have types. Types ease program checking and preparation of execution on machines. Instead, Smalltalk provides classes to resolve call to methods. Instead of relying on class tags, we can also rely on object sets (called contexts), solve binding on these object sets, and produce logic networks that will replace the slow interpretation or execution by one call to a dedicated function block. Computer operative parts are either logic networks, combinational or sequential, defined at boolean level. Thus this schema is the common way to produce operative blocks, even dynamically. The first stage is a high level look-up table tree production organized around method calls, with evolved backtracking memory optimizers. This could be suitable for architectures such as GPUs or memory based nano-architectures. The second stage is mapping to reconfigurable architectures, expecially those oriented to logic, such as FPGAs. The Madeo framework address Smalltalk to technology translation in its different stages address this question, such as: [FCCM96] Smalltalk blocks to logic, 4th IEEE Symposium on FPGAs for Custom Computing Machines (FCCM '96), Napa Valley, CA, USA, April 17-19, 1996. IEEE 1996, ISBN 0-8186-7548-9 also at http://wsn.univ-brest.fr/reports/96/st80-2-FPGA.ps.Z <http://wsn.univ-brest.fr/reports/96/st80-2-FPGA.ps.Z> [SAMOS2002] A LUT based approach for high level synthesis, Shuvra S. Bhattacharyya, E.F. Deprettere, Jurgen Teich, (Eds.), Domain-Specific Processors: Systems, Architectures, Modeling, and Simulation, Hardcover, pp. 261, plus XV, Marcel Dekker, Inc., New York, 2004, ISBN 0-8427-4711-9 also at http://wsn.univ-brest.fr/reports/2002/samos2.pdf <http://wsn.univ-brest.fr/reports/2002/samos2.pdf> 4) Mapping LUT systems to hardware were addressed by two excellent PhD works, one that draws a flattened LUT tree on an FPGA, the other one that address nano technologies, largely connected to Pr Moritz work at Umass. As a conclusion (I hope it is not final), there are large opportunities to improve specific execution speed of Smalltalk engines using new 'back to the future' approaches. We just need to stop doing bad copies of the sacred 40 years implementation, pretending that it is a 'virtual machine' for today, look to GPUs, reconfigurable devices, and new technologies especially those based on low energy and fast physical memories. Bernard Pottier UniversiteÌ de Brest, France pottier(a)univ-brest.fr <mailto:pottier@univ-brest.fr> > Am 17.04.2019 um 01:00 schrieb Sean Glazier <sglazier456(a)gmail.com <mailto:sglazier456@gmail.com>>: > > This sounds great do they need a great Smalltalker? My linked in profile is www.linkedin.com/in/seanglazier <http://www.linkedin.com/in/seanglazier> I would love to be a contributor > > Kind Regards, > > Sean Glazier > > On Mon, Apr 15, 2019 at 4:33 PM Bernhard HÃ¶fner <bernhard.hoefner(a)web.de <mailto:bernhard.hoefner@web.de>> wrote: > Thank you, Helge, I had no clue but I felt something like this. > â¦at least it would be an excellent advertisement for Smalltalk when it succeeds and therefore maybe it would be worth to harness the forces in the Smalltalk community, no matter if Squeak, Pharo, VisualWorksâ¦ > But Smalltalk will not have any effect without an excellent partner for hardware and for AI algorithms. Maybe the suitable Fraunhofer institute? At least they invented mp3. > > Best regards, Bernhard > > >> Am 15.04.2019 um 17:54 schrieb Nowak, Helge <HNowak(a)cincom.com <mailto:HNowak@cincom.com>>: >> >> Dear Bernhard, Alexandre and all, <> >> >> Thanks Bernhard for pointing to this. I would have missed it completelyâ¦ >> >> The German BMBF (Bundesministerium fÃ¼r Bildung und Forschung = German Federal Ministry of Research and Technology) started this competition for German universities and public research centers. It is targeted at increasing energy efficiency for AI systems. The aim is to increase Germanyâs competencies and competitiveness in this sector which is deemed to be a future key technology with the potential of disruptive innovation. >> >> It is clear that the energy efficiency is less determined by what programming language is used and what virtual machine is run on some standard hardware. The real gains are rather found in maybe novel algorithms, surely in novel hardware architectures and implementations. Indeed, when you look at the details of the competition (link below) that is exactly the case: any proposed solutions submitted to the competition must belong to one of three categories: FPGAs, ASIC s in 130 nm technology or ASICs in FDSOI technology. Close hardware/software co-design is explicitly requested. Not eligible are solutions that only optimize software components or use commercially available hardware unchanged. >> >> Does this mean that this competition is of no interest to ambitious Smalltalkers? No! In contrary. With Smalltalk being a perfect interactive modeling, exploration and simulation tool we Smalltalkers can help our competition team to build, explore and optimize their ideas before and while building them in hardware. Also hardware is nothing without software. Smalltalk is in my view best positioned to execute the desired co-design in a co-evolutionary way. Certainly we could demonstrate modern âagileâ engineering approaches as a side-means to increase competitiveness. >> >> Everyone interested should take a look at the competition here:https://www.bmbf.de/foerderungen/bekanntmachung-2371.html <https://www.bmbf.de/foerderungen/bekanntmachung-2371.html> (in German, obviously). >> >> Please also forward to all people who might be interested. >> >> Cheers >> Helge >> >> Helge Nowak >> Cincom Smalltalk Technical Account Manager >> <image001.png> <http://www.cincomsmalltalk.com/> >> >> Cincom Systems GmbH & Co. oHG >> HumboldtstraÃe 3 >> 60318 Frankfurt am Main >> GERMANY > >> office >> mobile >> >> website >> email >> +49 89 89 66 44 94 >> +49 172 74 00 402 >> >> http://www.cincomsmalltalk.com <http://www.cincomsmalltalk.com/> >> hnowak(a)cincom.com <mailto:hnowak@cincom.com> >> A standpoint is an intellectual horizon of radius zero. -- Albert Einstein >> >> GeschÃ¤ftsfÃ¼hrer/Managing Directors: Thomas M. Nies, Donald E. Vick >> oHG mit Sitz/based in Frankfurt am Main (Amtsgericht Frankfurt am Main HRA 50297) >> Pers. haftender Gesellschafter/Partner liable to unlimited extent: >> Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht KÃ¶nigstein/Ts. HRB 5069) >> >> --- CONFIDENTIALITY STATEMENT --- >> This e-mail transmission contains information that is intended to be privileged and confidential. It is intended only for the addressee named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited, please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. > >> >> >> Von: Alexandre Bergel [mailto:alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>] >> Gesendet: Freitag, 12. April 2019 19:08 >> An: Bernhard HÃ¶fner <bernhard.hoefner(a)web.de <mailto:bernhard.hoefner@web.de>> >> Cc: VisualWorks mailing list list <vwnc(a)cs.uiuc.edu <mailto:vwnc@cs.uiuc.edu>>; pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >> Betreff: Re: [vwnc] most energy efficient AI system - challenge of the German Federal Ministry of Education and Research BMBF >> >> Hello, >> >> We conducted some experiment in characterizing virtual machine from an energetic point of view. Results are not public yet. This is just to say this is a topic that I am interested in. >> >> Cheers, >> Alexandre >> >> >> On Apr 11, 2019, at 5:29 PM, Bernhard HÃ¶fner <bernhard.hoefner(a)web.de <mailto:bernhard.hoefner@web.de>> wrote: >> >> Hello Group, >> the German BMBF advertised a reward for the most energy efficient AI system, see: https://www.bmbf.de/de/mehr-ki-erfordert-weniger-energie-8156.html <https://www.bmbf.de/de/mehr-ki-erfordert-weniger-energie-8156.html> (in German), and I am wondering what is the position of Smalltalk in that field or what it could be. From the early 90th I know that much of the pretended slowness of Smalltalk was absorbed by the more efficient programs due to better analysis, concepts, design and development tools (and maybe developers ? ). >> >> Best Regards, Bernhard > > -- > > Kind Regards, > > Sean Glazier > 603 892 0167 cell > 603 583 4575 Skype phone > Skype Id: visualwave >

1 0

Re: [Pharo-dev] [vwnc] most energy efficient AI system - challenge of the German Federal Ministry of Education and Research BMBF
by Bernhard HÃ¶fner April 24, 2019

April 24, 2019

Hello group, Bernard Portier from University Brest allowed me to forward his ideas referring to works of different scientists. It may help to concretize an AI-project or to fertilize discussion. I am not an AI-specialist and sorry not to be able to participate on a discussion. Best Regards, Bernhard â¦ Dear Bernhard, This is a summary of work done at University of Brest for mapping Smalltalk computation to hardware. 1) efficiency is concurrency in execution During decades researchers and industry was running behind the work of Xerox PARC on micro- programmed computers, such as the Dorado. The Dorado implemented a pipeline for decoding languages intermediate code developped for this purpose. Smalltalk bytecodes as delivered for Smalltalk-80 were of this kind. Behind the streaming engine that prepared the execution, there was the micro-machine routines translated by PARC into micro-program control executing several internal operations in parallel. The blue book implementation part is just a description of how the instructions are executed. (For those who do not know about micro-programming, there are primers written in the 70's by Michael Flynn to explain link between the instruction set, micro-program structure, and program execution. It takes 1 day to read, understand, and experiment: look at Ci lines that activate concurrent operations from a micro-code word.) [Flynn] Micro-programming, includes Rosin machine, in Computer Architecture 1972. Annex 1. [Dorado] Retrospective, Pier. http://bitsavers.trailing-edge.com/pdf/xerox/parc/techReports/ISL-83 <http://bitsavers.trailing-edge.com/pdf/xerox/parc/techReports/ISL-83>- 1_A_Retrospective_on_the_Dorado_A_High-Performance_Personal_Computer.pdf So, Smalltalk was fast enough in 1980, it was well understood for a machine execution, and became so slow when executed on micro processors, despite valuable efforts at UCBerkeley, Stanford and others. 2) concurrency is now easily available Probably one could implement Rosin machine in few days, plus a compiler to translate a calculator syntax into instruction set for it. Research could rather examine chances to execute high level computer language at the current level of resources as FPGAs devices and shared memory accelerators. In the second case, one can recall that previous generation of massive parallel computers used Smalltalk to model execution. It was the case for Maspar machine which debugger was showing clearly a ParcPlace support to display assertions on parallel (plural) variables. This debugger inspired some work to support parallel execution on GPU as shown in [VanLong]. [VanLong] Master report. Annex 2. http://wsn.univ-brest.fr/pottier/long.pdf <http://wsn.univ-brest.fr/pottier/long.pdf> (See also https://www.mdpi.com/1424-8220/18/7/2323 <https://www.mdpi.com/1424-8220/18/7/2323> about parallel physical simulation) 3) execution and definition of object spaces can replace types. Smalltalk does not have types. Types ease program checking and preparation of execution on machines. Instead, Smalltalk provides classes to resolve call to methods. Instead of relying on class tags, we can also rely on object sets (called contexts), solve binding on these object sets, and produce logic networks that will replace the slow interpretation or execution by one call to a dedicated function block. Computer operative parts are either logic networks, combinational or sequential, defined at boolean level. Thus this schema is the common way to produce operative blocks, even dynamically. The first stage is a high level look-up table tree production organized around method calls, with evolved backtracking memory optimizers. This could be suitable for architectures such as GPUs or memory based nano-architectures. The second stage is mapping to reconfigurable architectures, expecially those oriented to logic, such as FPGAs. The Madeo framework address Smalltalk to technology translation in its different stages address this question, such as: [FCCM96] Smalltalk blocks to logic, 4th IEEE Symposium on FPGAs for Custom Computing Machines (FCCM '96), Napa Valley, CA, USA, April 17-19, 1996. IEEE 1996, ISBN 0-8186-7548-9 also at http://wsn.univ-brest.fr/reports/96/st80-2-FPGA.ps.Z <http://wsn.univ-brest.fr/reports/96/st80-2-FPGA.ps.Z> [SAMOS2002] A LUT based approach for high level synthesis, Shuvra S. Bhattacharyya, E.F. Deprettere, Jurgen Teich, (Eds.), Domain-Specific Processors: Systems, Architectures, Modeling, and Simulation, Hardcover, pp. 261, plus XV, Marcel Dekker, Inc., New York, 2004, ISBN 0-8427-4711-9 also at http://wsn.univ-brest.fr/reports/2002/samos2.pdf <http://wsn.univ-brest.fr/reports/2002/samos2.pdf> 4) Mapping LUT systems to hardware were addressed by two excellent PhD works, one that draws a flattened LUT tree on an FPGA, the other one that address nano technologies, largely connected to Pr Moritz work at Umass. As a conclusion (I hope it is not final), there are large opportunities to improve specific execution speed of Smalltalk engines using new 'back to the future' approaches. We just need to stop doing bad copies of the sacred 40 years implementation, pretending that it is a 'virtual machine' for today, look to GPUs, reconfigurable devices, and new technologies especially those based on low energy and fast physical memories. Bernard Pottier UniversiteÌ de Brest, France pottier(a)univ-brest.fr <mailto:pottier@univ-brest.fr> the text as pdf: > Am 17.04.2019 um 01:00 schrieb Sean Glazier <sglazier456(a)gmail.com>: > > This sounds great do they need a great Smalltalker? My linked in profile is www.linkedin.com/in/seanglazier <http://www.linkedin.com/in/seanglazier> I would love to be a contributor > > Kind Regards, > > Sean Glazier > > On Mon, Apr 15, 2019 at 4:33 PM Bernhard HÃ¶fner <bernhard.hoefner(a)web.de <mailto:bernhard.hoefner@web.de>> wrote: > Thank you, Helge, I had no clue but I felt something like this. > â¦at least it would be an excellent advertisement for Smalltalk when it succeeds and therefore maybe it would be worth to harness the forces in the Smalltalk community, no matter if Squeak, Pharo, VisualWorksâ¦ > But Smalltalk will not have any effect without an excellent partner for hardware and for AI algorithms. Maybe the suitable Fraunhofer institute? At least they invented mp3. > > Best regards, Bernhard > > >> Am 15.04.2019 um 17:54 schrieb Nowak, Helge <HNowak(a)cincom.com <mailto:HNowak@cincom.com>>: >> >> Dear Bernhard, Alexandre and all, <> >> >> Thanks Bernhard for pointing to this. I would have missed it completelyâ¦ >> >> The German BMBF (Bundesministerium fÃ¼r Bildung und Forschung = German Federal Ministry of Research and Technology) started this competition for German universities and public research centers. It is targeted at increasing energy efficiency for AI systems. The aim is to increase Germanyâs competencies and competitiveness in this sector which is deemed to be a future key technology with the potential of disruptive innovation. >> >> It is clear that the energy efficiency is less determined by what programming language is used and what virtual machine is run on some standard hardware. The real gains are rather found in maybe novel algorithms, surely in novel hardware architectures and implementations. Indeed, when you look at the details of the competition (link below) that is exactly the case: any proposed solutions submitted to the competition must belong to one of three categories: FPGAs, ASIC s in 130 nm technology or ASICs in FDSOI technology. Close hardware/software co-design is explicitly requested. Not eligible are solutions that only optimize software components or use commercially available hardware unchanged. >> >> Does this mean that this competition is of no interest to ambitious Smalltalkers? No! In contrary. With Smalltalk being a perfect interactive modeling, exploration and simulation tool we Smalltalkers can help our competition team to build, explore and optimize their ideas before and while building them in hardware. Also hardware is nothing without software. Smalltalk is in my view best positioned to execute the desired co-design in a co-evolutionary way. Certainly we could demonstrate modern âagileâ engineering approaches as a side-means to increase competitiveness. >> >> Everyone interested should take a look at the competition here:https://www.bmbf.de/foerderungen/bekanntmachung-2371.html <https://www.bmbf.de/foerderungen/bekanntmachung-2371.html> (in German, obviously). >> >> Please also forward to all people who might be interested. >> >> Cheers >> Helge >> >> Helge Nowak >> Cincom Smalltalk Technical Account Manager >> <image001.png> <http://www.cincomsmalltalk.com/> >> >> Cincom Systems GmbH & Co. oHG >> HumboldtstraÃe 3 >> 60318 Frankfurt am Main >> GERMANY > >> office >> mobile >> >> website >> email >> +49 89 89 66 44 94 >> +49 172 74 00 402 >> >> http://www.cincomsmalltalk.com <http://www.cincomsmalltalk.com/> >> hnowak(a)cincom.com <mailto:hnowak@cincom.com> >> A standpoint is an intellectual horizon of radius zero. -- Albert Einstein >> >> GeschÃ¤ftsfÃ¼hrer/Managing Directors: Thomas M. Nies, Donald E. Vick >> oHG mit Sitz/based in Frankfurt am Main (Amtsgericht Frankfurt am Main HRA 50297) >> Pers. haftender Gesellschafter/Partner liable to unlimited extent: >> Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht KÃ¶nigstein/Ts. HRB 5069) >> >> --- CONFIDENTIALITY STATEMENT --- >> This e-mail transmission contains information that is intended to be privileged and confidential. It is intended only for the addressee named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited, please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. > >> >> >> Von: Alexandre Bergel [mailto:alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>] >> Gesendet: Freitag, 12. April 2019 19:08 >> An: Bernhard HÃ¶fner <bernhard.hoefner(a)web.de <mailto:bernhard.hoefner@web.de>> >> Cc: VisualWorks mailing list list <vwnc(a)cs.uiuc.edu <mailto:vwnc@cs.uiuc.edu>>; pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >> Betreff: Re: [vwnc] most energy efficient AI system - challenge of the German Federal Ministry of Education and Research BMBF >> >> Hello, >> >> We conducted some experiment in characterizing virtual machine from an energetic point of view. Results are not public yet. This is just to say this is a topic that I am interested in. >> >> Cheers, >> Alexandre >> >> >> On Apr 11, 2019, at 5:29 PM, Bernhard HÃ¶fner <bernhard.hoefner(a)web.de <mailto:bernhard.hoefner@web.de>> wrote: >> >> Hello Group, >> the German BMBF advertised a reward for the most energy efficient AI system, see: https://www.bmbf.de/de/mehr-ki-erfordert-weniger-energie-8156.html <https://www.bmbf.de/de/mehr-ki-erfordert-weniger-energie-8156.html> (in German), and I am wondering what is the position of Smalltalk in that field or what it could be. From the early 90th I know that much of the pretended slowness of Smalltalk was absorbed by the more efficient programs due to better analysis, concepts, design and development tools (and maybe developers ? ). >> >> Best Regards, Bernhard > > -- > > Kind Regards, > > Sean Glazier > 603 892 0167 cell > 603 583 4575 Skype phone > Skype Id: visualwave >

1 0

Lectures at Montreal
by StÃ©phane Ducasse April 23, 2019

April 23, 2019

Hello Just a little mail to mention that I will visit montreal and give some lectures 23 and 24 of May. If Montreal Smalltalkers want to discuss let me know. Stef -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

1 0

[Pharo 8.0] Build #232: 3196-ObjectLayout: remove var compactClassIndex
by ci-pharo-ci-jenkins2＠inria.fr April 20, 2019

April 20, 2019

There is a new Pharo build available! The status of the build #232 was: SUCCESS. The Pull Request #3208 was integrated: "3196-ObjectLayout: remove var compactClassIndex" Pull request url: https://github.com/pharo-project/pharo/pull/3208 Issue Url: https://github.com/pharo-project/pharo/issues/MarcusDenker Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #231: 3206-NautilusRefactoring-contains-dead-code
by ci-pharo-ci-jenkins2＠inria.fr April 20, 2019

April 20, 2019

There is a new Pharo build available! The status of the build #231 was: FAILURE. The Pull Request #3207 was integrated: "3206-NautilusRefactoring-contains-dead-code" Pull request url: https://github.com/pharo-project/pharo/pull/3207 Issue Url: https://github.com/pharo-project/pharo/issues/3206 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)
by StÃ©phane Ducasse April 20, 2019

April 20, 2019

> > > Hi Esteban, > > This is fantastic! We are eager to investigate how Roassal3 can run in an external window. this will possible even without GTK3 :) Stef > > Alexandre > >> On Apr 18, 2019, at 6:08 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced: >> >> We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings! >> >> Why we want a Spec 2.0 with different backends? >> >> There are reasons that converged to decide us to make it: >> >> â¢ First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic). >> â¢ Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the "next big thing" (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons: >> â¢ Because there is still an important place for desktop applications market and most medium-size to big business still require them. >> â¢ Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it). >> >> For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless: Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come. >> >> Why Gtk3? >> >> There are some other important players in the "native widgets scene", so why we choose Gtk3? >> >> Again, several reasons were taken into account: >> >> â¢ Gtk3 is cross platform. Yes, technically is just "native" in linux, but it works on Windows and macOS too. >> â¢ It is very mature and popular. >> â¢ It is made in plain C. >> >> Next step: tool migration >> >> The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them: >> >> â¢ Old GT tools will be replaced by new Spec tools (while preserving its power). >> â¢ Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now). >> â¢ Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings. >> >> And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately :) >> >> >> A small screenshot of the new Inspector (WIP): >> >> <Screenshot 2019-04-18 at 12.07.16.png> >> >> Esteban > > > > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

1 0

Any experts on using path in app bundles willing to help me?
by Eliot Miranda April 20, 2019

April 20, 2019

Hi All, I have a plugin dependent on several support libraries that may be shared with other plugins. So I want the support libraries in a common place (TheVm.app/Contents/Frameworks) while the plugins themselves are bundles in TheVM.app/Contents/Resources. In allowing one to install plugin support libraries in TheVM.app/Contents/Frameworks I have to use the linker's -rpath feature to specify where dlopen may find the search libraries. The question i don't see an answer to in Apple's documentation is whether one uses -rpath when linking the plugin, or when linking the VM into which the plugin will be loaded, or both. Anybody ever done this and know definitively what to do? _,,,^..^,,,_ best, Eliot

3 5

Small Pharo developer contract
by ducasse April 20, 2019

April 20, 2019

Hi guys This may interest some of you. Stef

1 0

[ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)
by Esteban Lorenzano April 19, 2019

April 19, 2019

People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced: We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings! Why we want a Spec 2.0 with different backends? There are reasons that converged to decide us to make it: First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic). Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the "next big thing" (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons: Because there is still an important place for desktop applications market and most medium-size to big business still require them. Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it). For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless: Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come. Why Gtk3? There are some other important players in the "native widgets scene", so why we choose Gtk3? Again, several reasons were taken into account: Gtk3 is cross platform. Yes, technically is just "native" in linux, but it works on Windows and macOS too. It is very mature and popular. It is made in plain C. Next step: tool migration The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them: Old GT tools will be replaced by new Spec tools (while preserving its power). Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now). Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings. And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately :) A small screenshot of the new Inspector (WIP): Esteban

3 3