- Pharo-dev - lists.pharo.org

Inovation Technology Award Submission: Polyphemus

by pmissech

Hello, Although i will not be able to attend ESUG'22, a friend agreed to present one of our projects to the innovation award. **Polyphemus** is aÂ VM related, but public aims at any kind of developers. Particularly, the video submission talks about how to look at an image and how to **recover** dead images. Feel free to contact me if you have any questions ! Enjoy (and vote for Polyphemus!). 5 minutes video, Innovation Technology Award submission: https://youtu.be/zf3cCtNW830 Repository: github.com/hogoww/Polyphemus/ Additionnal information on image recovery: https://github.com/hogoww/Polyphemus/blob/main/Documentation/ResurrectingDe… Cheers !

Aug. 16, 2022

MPLR 2022 -- Call for Participation

by Guillermo Polito

======================================================================== Call for Participation MPLR 2022 - 19th International Conference on Managed Programming Languages & Runtimes September 14-15, 2022 in Brussels, Belgium https://soft.vub.ac.be/mplr22/ Follow us @MPLR_Conf ======================================================================== The 19th International Conference on Managed Programming Languages & Runtimes (MPLR, formerly ManLang) is a premier forum for presenting and discussing novel results in all aspects of managed programming languages and runtime systems, which serve as building blocks for some of the most important computing systems in use, ranging from small-scale (embedded and real-time systems) to large-scale (cloud-computing and big-data platforms) and anything in between (desktop, mobile, IoT, and wearable applications). This year, MPLR will be held at the campus of the Vrije Universiteit Brussel(VUB) in Brussels, Belgium. Keynotes -------- Performance Optimizations in the .NET GC Dr. Maoni Stephens, Microsoft, USA Static Compilation of JavaScript Dr. Manuel Serrano, Inria Sophia-Antipolis, France Accepted Papers --------------- Automatic Array Transformation to Columnar Storage at Run Time Lukas Makor et al. Compressed Forwarding Tables Reconsidered Jonas Norlinder et al. Event-Based Out-of-place Debugging Tom Lauwaerts et al. Machine-Learning-Based Self-Optimizing Compiler Heuristics Raphael Mosaner et al. SecSharp: Towards Efficient Trusted Execution in Managed Languages Gilang Mentari Hamidy et al. A Model Checking Framework for a New Collector Framework Bochen Xu et al. Porting a JIT compiler to RISC-V: Challenges and Opportunities Quentin Ducasse et al. Analyzing and Predicting Energy Consumption of Garbage Collectors in OpenJDK Marina Shimchenko et al. Better Understanding the Costs and Benefits of Automatic Memory Management Kunal Sareen et al. Dynamic Taint Analysis with Label-Defined Semantics Jacob Kreindl et al. Attendance ---------- Thanks to our generous sponsors, we were able to significantly reduce this yearâs registration fees. Early Registration Fees: Students: 175 Euro Regular: 250 Euro In addition to the conference participation, the registration includes: - 2-day transportation ticket in the Brussels area - welcome reception on Wednesday, September 14 - guided tour to the city hall and conference banquet on Thursday, September 15 More details, and link to registration system: https://soft.vub.ac.be/mplr22/registration/ Important Dates --------------- Early Registration: 23 August 2022 Conference Dates: 14-15 September 2022

Aug. 16, 2022

about object serialization and deserialization

by stephane ducasse

Hi guys It is interesting to think about the design and use of object deserializers. https://www.slideshare.net/frohoff1/deserialize-my-shorts-or-how-i-learned-…

Aug. 15, 2022

Re: [Pharo-users] Omnibase/Monibase repository removal

by stephane ducasse

> On 12 Aug 2022, at 07:25, Yanni Chiu <yannix7db(a)gmail.com <mailto:yannix7db@gmail.com>> wrote: > > Sounds good. Using Fuel to serialize/deserialize should be fine, but I had unhappy experience with early versions where a newer Fuel version could not read content written by earlier Fuel versions. I agree with you. It ws an important requirements that got dropped. And then after we never got to time to revisit it and I always felt ashamed because migrating data is super important to me.

Aug. 12, 2022

Re: [Pharo-users] Omnibase/Monibase repository removal

by Norbert Hartl

hi Yanni, > Am 12.08.2022 um 07:25 schrieb Yanni Chiu <yannix7db(a)gmail.com>: > > Sounds good. Using Fuel to serialize/deserialize should be fine, but I had unhappy experience with early versions where a newer Fuel version could not read content written by earlier Fuel versions. That is indeed the weakest part of Fuel I know and something I need to take care off. I will use Fuel without that part of the header that barks on versions. What needs to be done is to see what changed between versions and make a way to migrate. For this the database files will most likely have a version that is dedicated to the Fuel version being used. > > In my mind, a disk-based B-tree is the fundamental data structure for any database (e.g. GemStone, Omnibase, Relational DBs all have it), but I donât see it mentioned so far. Everything else about a "database" is optional, IMHO. > Ah, right, I didn't write about it but it is essential. My plan would be to also have a disk based b-tree dictionary that can keep parts like the keys (maybe even incrementally) in memory. But I'm not an expert in b-trees so I need to figure out what is the gap between the requirements of a b-tree and my plans ;) Also b-tree will come later after you are able to write/read something reliable. > For example, a query language is not needed at all, if the data items are equivalent to objects running in a Smalltalk VM - the query language is Smalltalk itself. It âjustâ has to mesh well with the indexing. > I think it needs a query DSL. Using blocks has serious limitations doing a proper query. The usage of instVars needs to be well known in order to analyze a query for index usage. Furthermore is the problem like #collect:thenSelect: even more severe in a database. So for indexes and query optimizations it should be a query DSL that is more like aCollection select firstName = 'Norbert' I will experiment a bit. The combination of multiple queries in smalltalk and using binary messages is a problem of its own. > Another feature is MVCC. How much concurrency is needed, and how it is implemented, is an implementation choice. Iâd mentioned LMDB on Discord. It has single writer, many readers. Choosing to have multiple simultaneous writers has a cost. When there is one or more big machines, it seems sensible have the big machines use multiple writers. But when these databases scale up, the database ends up sharded, with parts of the data spread over multiple machines. Why not just start there, with many small machines owning a small part of the database, and use just a single writer process. The application can then deal with concurrency, conflicts and assembling results, in whatever manner best suits. > Almost all databases have only a single writer for one set of data. Sharding is a way to have virtual partitions of your data where you can have a writer per virtual partition removing the conflit potential. MVCC is not about having multiple writers as it is hardly possible. The benefits of MVCC are that data in a transaction is fully isolated and writers do not block readers. I personally like that a MVCC database is an append-only store for object data. You have to have one concurrency approach and MVCC is not really hard to implement. In ApptiveGrid we have a fully partioned model per user where inter-user-references use URNs as content address notation. This way we have hundreds of databases where each has a single writer. This is my main focus but I think we are on the same page regarding that. If nothing changes my talk at ESUG will talk about this. > So I see the end goal to be a set of frameworks, and some ârecipesâ for putting the frameworks together, to solve the âpersistenceâ problem. These are just half-baked ideas of course. Iâll follow the project, and hope to contribute. Thanks. I don't how far this project will get. But I have a need and ideas. Just need time :) Let's see where the journey gets. Norbert > > Yanni > > On Wed, Aug 10, 2022 at 7:08 AM Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > FYI > > As the license situation around Omnibase is unlikely to change and such a license is not an enabler for collaboration I came to the conclusion that there is no other way than to start a new OO database (what a surprise! :) ) > > If you are interested or want to see what will happen in the next months you can have a look at > > https://github.com/ApptiveGrid/Soil <https://github.com/ApptiveGrid/Soil> > > After half a day of work it can already serialize and partition a simple graph and store it to disk in a way it can be read back even when partitioned. Thanks to having Fuel we do not need to reinvent the wheel and have serialization/materialization done. > Of course this is super simple and does not comes close to anything usable but a good start. I've also added a documentation in the github repo to describe the most important parts for me that I will target. > > Questions, critiques and laughs are appreciated, > > Norbert > >> Am 08.08.2022 um 15:18 schrieb Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>>: >> >> To all Omnibase and Monibase users. >> >> It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from >> >> https://github.com/ApptiveGrid/MoniBase <https://github.com/ApptiveGrid/MoniBase> >> >> and >> >> https://github.com/pharo-nosql/OmniBase <https://github.com/pharo-nosql/OmniBase> >> >> I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away. >> >> As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase. >> >> regards, >> >> Norbert >

Aug. 12, 2022

Re: [Pharo-users] Omnibase/Monibase repository removal

by Yanni Chiu

Sounds good. Using Fuel to serialize/deserialize should be fine, but I had unhappy experience with early versions where a newer Fuel version could not read content written by earlier Fuel versions. In my mind, a disk-based B-tree is the fundamental data structure for any database (e.g. GemStone, Omnibase, Relational DBs all have it), but I donât see it mentioned so far. Everything else about a "database" is optional, IMHO. For example, a query language is not needed at all, if the data items are equivalent to objects running in a Smalltalk VM - the query language is Smalltalk itself. It âjustâ has to mesh well with the indexing. Another feature is MVCC. How much concurrency is needed, and how it is implemented, is an implementation choice. Iâd mentioned LMDB on Discord. It has single writer, many readers. Choosing to have multiple simultaneous writers has a cost. When there is one or more big machines, it seems sensible have the big machines use multiple writers. But when these databases scale up, the database ends up sharded, with parts of the data spread over multiple machines. Why not just start there, with many small machines owning a small part of the database, and use just a single writer process. The application can then deal with concurrency, conflicts and assembling results, in whatever manner best suits. So I see the end goal to be a set of frameworks, and some ârecipesâ for putting the frameworks together, to solve the âpersistenceâ problem. These are just half-baked ideas of course. Iâll follow the project, and hope to contribute. Yanni On Wed, Aug 10, 2022 at 7:08 AM Norbert Hartl <norbert(a)hartl.name> wrote: > FYI > > As the license situation around Omnibase is unlikely to change and such a > license is not an enabler for collaboration I came to the conclusion that > there is no other way than to start a new OO database (what a surprise! :) ) > > If you are interested or want to see what will happen in the next months > you can have a look at > > https://github.com/ApptiveGrid/Soil > > After half a day of work it can already serialize and partition a simple > graph and store it to disk in a way it can be read back even when > partitioned. Thanks to having Fuel we do not need to reinvent the wheel and > have serialization/materialization done. > Of course this is super simple and does not comes close to anything usable > but a good start. I've also added a documentation in the github repo to > describe the most important parts for me that I will target. > > Questions, critiques and laughs are appreciated, > > Norbert > > Am 08.08.2022 um 15:18 schrieb Norbert Hartl <norbert(a)hartl.name>: > > To all Omnibase and Monibase users. > > It turned out that neither of those are open source. The author of the > database contacted me clarifying the situation that he has the copyright > and never released something open source. This means that I will remove the > Omnibase repositories in few weeks from > > https://github.com/ApptiveGrid/MoniBase > > and > > https://github.com/pharo-nosql/OmniBase > > I'm very sorry about that but someone just took the code 9 years before, > copied it on github and put illegally an MIT license to the repository. We > only want free software in our repositories and hence the above will go > away. > > As we see it essential to have a good OO database in pharo we will see how > much effort it will be build a small and simple OO database that can > replace Omnibase. > > regards, > > Norbert > > >

Aug. 12, 2022

Smalltalks 2022: call for registration, talks and sponsors!

by Mariano Martinez Peck

Greetings everyone, The Smalltalks conference is back in Argentina! From Nov 9th to 11th at the 0+Inf building of Facultad de Ciencias Exactas y Naturales, UBA , Buenos Aires. We will celebrate the 50 years of Smalltalk-72 with Dan Ingalls , its main developer, Gilad Bracha and many others. Feel free to register already or submit talks [1]. We welcome all types of presentations: commercial products, experience reports, tooling, virtual machines, research, frameworks & applications, education, etc. You may also consider becoming a sponsor [2] as that is what allows the conference to be free and accessible to everybody. Thanks for sharing the news! [1] https://smalltalks2022.fast.org.ar [2] https://smalltalks2022.fast.org.ar/sponsoring -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: www.linkedin.com/in/mariano-martinez-peck <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> Blog: https://marianopeck.wordpress.com/

Aug. 10, 2022

Re: [Pharo-users] Omnibase/Monibase repository removal

by Norbert Hartl

FYI As the license situation around Omnibase is unlikely to change and such a license is not an enabler for collaboration I came to the conclusion that there is no other way than to start a new OO database (what a surprise! :) ) If you are interested or want to see what will happen in the next months you can have a look at https://github.com/ApptiveGrid/Soil <https://github.com/ApptiveGrid/Soil> After half a day of work it can already serialize and partition a simple graph and store it to disk in a way it can be read back even when partitioned. Thanks to having Fuel we do not need to reinvent the wheel and have serialization/materialization done. Of course this is super simple and does not comes close to anything usable but a good start. I've also added a documentation in the github repo to describe the most important parts for me that I will target. Questions, critiques and laughs are appreciated, Norbert > Am 08.08.2022 um 15:18 schrieb Norbert Hartl <norbert(a)hartl.name>: > > To all Omnibase and Monibase users. > > It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from > > https://github.com/ApptiveGrid/MoniBase <https://github.com/ApptiveGrid/MoniBase> > > and > > https://github.com/pharo-nosql/OmniBase <https://github.com/pharo-nosql/OmniBase> > > I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away. > > As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase. > > regards, > > Norbert

Aug. 10, 2022

Re: Omnibase/Monibase repository removal

by Dale Henrichs

Hereâs Kurtâs talk from Camp Smalltalk Supreme[1]. Dale [1] https://www.youtube.com/watch?v=uLF2S6fq5a4 Sent from my iPhone > On Aug 9, 2022, at 6:53 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > ï»¿Norbert, > > I wonât be going to ESUG this year â¦ travel to Europe has always been tough for me and at my age ð¨âð¦³I want to limit my exposure to COVIDâ¦ Perhaps next yearð¤. > > Dale > > Sent from my iPhone > >>> On Aug 9, 2022, at 3:21 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >> ï»¿Hi Dale, >> >> thanks for the pointer. I always admired what the GemStone people did and do. But I'm looking for something more lightweight and more easy to handle approach this time. Well, from the github page I could not derive what it really does to be honest. >> >> Hope to see you at ESUG, >> >> Norbert >> >>> Am 08.08.2022 um 18:44 schrieb Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: >>> >>> Norbert, >>> Before you go off and invent a data base, you might take a look at GemStone and RemoteServiceReplication[1] ... >>> >>> Dale >>> >>> [1] https://github.com/GemTalk/RemoteServiceReplication >>> >>>> On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norbert(a)hartl.name> wrote: >>>> To all Omnibase and Monibase users. >>>> >>>> It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from >>>> >>>> https://github.com/ApptiveGrid/MoniBase >>>> >>>> and >>>> >>>> https://github.com/pharo-nosql/OmniBase >>>> >>>> I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away. >>>> >>>> As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase. >>>> >>>> regards, >>>> >>>> Norbert >>

Aug. 9, 2022

Re: Omnibase/Monibase repository removal

by Dale Henrichs

Norbert, I wonât be going to ESUG this year â¦ travel to Europe has always been tough for me and at my age ð¨âð¦³I want to limit my exposure to COVIDâ¦ Perhaps next yearð¤. Dale Sent from my iPhone > On Aug 9, 2022, at 3:21 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > ï»¿Hi Dale, > > thanks for the pointer. I always admired what the GemStone people did and do. But I'm looking for something more lightweight and more easy to handle approach this time. Well, from the github page I could not derive what it really does to be honest. > > Hope to see you at ESUG, > > Norbert > >> Am 08.08.2022 um 18:44 schrieb Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: >> >> Norbert, >> Before you go off and invent a data base, you might take a look at GemStone and RemoteServiceReplication[1] ... >> >> Dale >> >> [1] https://github.com/GemTalk/RemoteServiceReplication >> >> On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norbert(a)hartl.name> wrote: >>> To all Omnibase and Monibase users. >>> >>> It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from >>> >>> https://github.com/ApptiveGrid/MoniBase >>> >>> and >>> >>> https://github.com/pharo-nosql/OmniBase >>> >>> I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away. >>> >>> As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase. >>> >>> regards, >>> >>> Norbert >

Aug. 9, 2022