Pharo-users
By thread
pharo-users@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- 1 participants
- 50346 messages
Re: ReStore and storing mixed dictionaries
by John Aspinall
Hi Offray - could you try modifying SSWReStore>>createProxyForNewObject: as follows:
...
table := self tableForClass: anObject class.
"Add this ->â table isNil ifTrue: [ self error: 'cannot find table for ', anObject class name ].
id := table idDataField ifNotNil: [ :idDataField | idDataField accessor valueIn: anObject].
â¦
This should change the error message to show the class of object which doesnât have a valid table.
Thanks.
John
> On 7 Apr 2022, at 20:29, Offray Vladimir Luna Cárdenas <offray.luna(a)mutabit.com> wrote:
>
> Hi John,
>
> Effectively ReStore didn't was storing the table object for the Nitter class. But after following your advice, i'm now able to debug both the TwitterUser and the NitterUser and obtain the same result (which makes sense as the later is inherited from the former). I think that my error was related with the definition of the synchronized tables, as I was not including explicitly the NitterUser (as I thought it would suffice with the TwitterUser one). Now it looks like this:
>
> ===
> ReStore connection: (SSWSQLite3Connection on: privateDatabase fullName);
> connect;
> addClasses: { Tweet. "TwitterUser." NitterUser };
> synchronizeAllClasses.
> ===
> Now I can get a non nil idDataField that has the same shape when #tableForClass: and "reStoreDefinition asTableIn: ReStore" are send to TwitterUser and NitterUser. Despite of that I still get the pre-commit error: "#idDataField was send to nil". Here is a screenshot of the trace of the error and the idDataFiled seems right (or at least equal to the same field in the TwitterUser):
> https://i.imgur.com/F3UDC93.png <https://i.imgur.com/F3UDC93.png>
> For the moment, I'm planing to use an extra/temporal TwitterStoreHelper object that stores via ReStore/SQLite the objects I'm unable to store so far, but as dictionaries of key/value helper objects, where the value is just the STON serialization of the object (with the inconveniences of not being able to query it properly). For example, a 'profiles' dictionary in TwitterStoreHelper would have a Twitter/Nitter user id as a key and its Ston representation as a value. It's a temporal workaround, while I debug the above error further.
> I'll keep you posted on the advances and regarding the booklet, I answered you in a direct message.
>
> Cheers,
>
> Offray
> On 7/04/22 2:59, John Aspinall wrote:
>> Hi Offray,
>>
>> Regarding the error, Iâm guessing that ReStore doesnât have a table object for your NitterUser class for some reason. Could you try:
>>
>> myReStore tableForClass: NitterUser
>>
>> â¦and check if this is returning nil? If so thereâs an issue with creating the table for the class; you could try stepping through
>>
>> NitterUser reStoreDefinition asTableIn: myReStore
>>
>> ...to get an idea of whatâs wrong.
>>
>> If this isnât the issue please let me know.
>>
>> Regarding the manual, Iâll send this to you by mail.
>>
>> Cheers.
>>
>> John
>>
>>
>>
>>> On 6 Apr 2022, at 19:48, Offray Vladimir Luna Cárdenas <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote:
>>>
>>> Thanks Jhon, it definitively helps.
>>>
>>> What I did was to extract some important metadata as slots of the Tweet object and made explicit the authorId, which allows me to trace tweets authorship:
>>>
>>> ===
>>> Tweet>>class #reStoreDefinition
>>> ^ super reStoreDefinition
>>> defineAsID: #id;
>>> define: #text as: String;
>>> define: #created as: String;
>>> define: #authorId as: String;
>>> define: #timelines as: (Dictionary of: String -> String); yourself
>>>
>>> ===
>>> Also I'm going to put in the radar the idea of storing STON strings for metadata residues.
>>>
>>> On a related matter, I'm still unable to store properly the NitterUser, which inherits from TwitterUser into SQLite and always get a pre-commit error: "#idDataField was send to nil" when I ran "myNitterUser store". Here is my TwitterUser storing definition:
>>>
>>> ===
>>> TwitterUser>>class #reStoreDefinition
>>> ^ super reStoreDefinition
>>> defineAsID: #id;
>>> define: #userName as: String;
>>> define: #profileImageUrl as: String;
>>> define: #profileBio as: String;
>>> "define: #createdAt as: String;"
>>> yourself.
>>>
>>> ===
>>>
>>> What I'm missing? And more importantly: how can I debug the message, so I can asign the proper non nil object as receiver of #idDataField ?
>>>
>>> Finally (for now ;-) ), the ReStore manual has been and important learning resource. Are you the author? And if so, would you be so kind to upload the Word source code to the Documentation/ folder in the repository under a permissive license that allow at least some format changes? We would like to add some table of contents and translate it to other formats, as we have done before with other free/libre cultural works (see [1] [2]).
>>>
>>> [1] https://mutabit.com/repos.fossil/datafem <https://mutabit.com/repos.fossil/datafem>
>>> [2] https://mutabit.com/repos.fossil/mapeda/ <https://mutabit.com/repos.fossil/mapeda/>
>>>
>>> Thanks,
>>>
>>> Offray
>>> On 6/04/22 2:52, John Aspinall wrote:
>>>> Hi Offray,
>>>>
>>>> Youâre correct that ReStore canât store that kind of mixed dictionary directly. You could store the entire STON text as one string and reify it on read, though that would mean you canât easily query on the metadata.
>>>>
>>>> A compromise solution would be to define objects and slots for the key data youâd need to query on and a STON string for the residue. This could be a better solution anyway as excessive/complex Dictionaries can be a sign that you need to define a new class/classes. For your particular project this would depend on how similar the metadata is between tweets - if thereâs not much commonality then a Dictionary approach may be more appropriate.
>>>>
>>>> Hope this helps,
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>>> On 5 Apr 2022, at 20:07, Offray Vladimir Luna Cárdenas <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> First of all, despite of being on a non-directly related matter with my question, congrats of Pharo 10.
>>>>>
>>>>> We (as now we have 2 active Smalltalkers in my country... Yay!) are creating a civic tech project with Pharo/Lepiter and we would like to store some Tweet metadata coming from Nitter[1]. As we're dealing with the differences between the official Twitter API and the unofficial Nitter one, we put the metadata we need in a dictionary that has several kinds of objects, from ordered collections to other dictionaries.
>>>>> [1] https://nitter.net/about <https://nitter.net/about>
>>>>> Currently if we serialize a Tweet object in STON, we get this:
>>>>>
>>>>> Tweet { #created : 'Tue, 05 Apr 2022 12:37:56 GMT', #text : '
>>>>>
>>>>> [ANN] Pharo 10 Released: pharo.org/news/pharo10-relea⦠<https://pharo.org/news/pharo10-released>\n', #id : '1511322244353597443', #user : NitterUser { #userName : 'pharoproject', #profileImageUrl : URL [ 'http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo… <http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo…>' ] }, #metadata : { 'queries' : OrderedCollection [ { 'date' : DateAndTime [ '2022-04-05T13:36:58.546011-05:00' ], 'parameters' : 'https://nitter.42l.fr/pharoproject <https://nitter.42l.fr/pharoproject>' } ], 'timelines' : { 'pharoproject' : '1511048498703126529' } } }
>>>>> As you can see, the metadata slot contains a dictionary with mixed classes of objects. But I read in the ReStore manual[2] (pg 14):
>>>>>
>>>>> """
>>>>>
>>>>> Like other collections, the class of elements for both key and value can be any other
>>>>> persistent class, and will be the same for all elements of that collection (except in the case of
>>>>> inheritance).
>>>>> """
>>>>> So, is ReStore unable to store metadata dictionaries like the one described in the previous STON code? if this is possible, how can I define it in the Tweet class>>reStoreDefinition?
>>>>> For the moment, I'm going to create a explicit "timelines" slot to store what was being stored at the #timelines key of the metadata dictionary. But, as metadata increases, instead of moving variables previously inside of a dictionary as explicit slots of an object, I think that having a explicit way of storing dictionaries with different kinds of objects, in contrast with only uniform ones, would be needed (but I don't know if this is in the design scope of ReStore).
>>>>>
>>>>> BTW, Lepiter has allow us to build a pretty fluent interface to browser Twitter/Nitter profiles and messages. Here it is how such UI looks for browsing last @pharoproject tweets:
>>>>>
>>>>> https://i.imgur.com/bxFze1g.png <https://i.imgur.com/bxFze1g.png>
>>>>> Any help on how to use ReStore in storing mixed dictionaries is appreciated.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Offray
>>>>
>>
April 7, 2022
Re: ReStore and storing mixed dictionaries
by Offray Vladimir Luna Cárdenas
Hi John,
Effectively ReStore didn't was storing the table object for the Nitter
class. But after following your advice, i'm now able to debug both the
TwitterUser and the NitterUser and obtain the same result (which makes
sense as the later is inherited from the former). I think that my error
was related with the definition of the synchronized tables, as I was not
including explicitly the NitterUser (as I thought it would suffice with
the TwitterUser one). Now it looks like this:
===
ReStore connection: (SSWSQLite3Connection on: privateDatabase fullName);
   connect;
   addClasses: { Tweet. "TwitterUser." NitterUser };
   synchronizeAllClasses.
===
Now I can get a non nil idDataField that has the same shape when
#tableForClass: and "reStoreDefinition asTableIn: ReStore" are send to
TwitterUser and NitterUser. Despite of that I still get the pre-commit
error: "#idDataField was send to nil". Here is a screenshot of the trace
of the error and the idDataFiled seems right (or at least equal to the
same field in the TwitterUser):
https://i.imgur.com/F3UDC93.png
For the moment, I'm planing to use an extra/temporal TwitterStoreHelper
object that stores via ReStore/SQLite the objects I'm unable to store so
far, but as dictionaries of key/value helper objects, where the value is
just the STON serialization of the object (with the inconveniences of
not being able to query it properly). For example, a 'profiles'
dictionary in TwitterStoreHelper would have a Twitter/Nitter user id as
a key and its Ston representation as a value. It's a temporal
workaround, while I debug the above error further.
I'll keep you posted on the advances and regarding the booklet, I
answered you in a direct message.
Cheers,
Offray
On 7/04/22 2:59, John Aspinall wrote:
> Hi Offray,
>
> Regarding the error, Iâm guessing that ReStore doesnât have a table
> object for your NitterUser class for some reason. Could you try:
>
> Â Â myReStore tableForClass: NitterUser
>
> â¦and check if this is returning nil? If so thereâs an issue with
> creating the table for the class; you could try stepping through
>
> Â Â NitterUser reStoreDefinition asTableIn: myReStore
>
> ...to get an idea of whatâs wrong.
>
> If this isnât the issue please let me know.
>
> Regarding the manual, Iâll send this to you by mail.
>
> Cheers.
>
> John
>
>
>
>> On 6 Apr 2022, at 19:48, Offray Vladimir Luna Cárdenas
>> <offray.luna(a)mutabit.com> wrote:
>>
>> Thanks Jhon, it definitively helps.
>>
>> What I did was to extract some important metadata as slots of the
>> Tweet object and made explicit the authorId, which allows me to trace
>> tweets authorship:
>>
>> ===
>> Tweet>>class #reStoreDefinition
>> ^ super reStoreDefinition
>> Â Â Â defineAsID: #id;
>> Â Â Â define: #text as: String;
>> Â Â Â define: #created as: String;
>> Â Â Â define: #authorId as: String;
>> Â Â Â define: #timelines as: (Dictionary of: String -> String); yourself
>>
>> ===
>>
>> Also I'm going to put in the radar the idea of storing STON strings
>> for metadata residues.
>>
>> On a related matter, I'm still unable to store properly the
>> NitterUser, which inherits from TwitterUser into SQLite and always
>> get a pre-commit error: "#idDataField was send to nil" when I ran
>> "myNitterUser store". Here is my TwitterUser storing definition:
>>
>> ===
>> TwitterUser>>class #reStoreDefinition
>>
>> Â Â Â ^ super reStoreDefinition
>> Â Â Â Â Â Â Â Â Â defineAsID: #id;
>> Â Â Â Â Â Â Â Â Â define: #userName as: String;
>> Â Â Â Â Â Â Â Â Â define: #profileImageUrl as: String;
>> Â Â Â Â Â Â Â Â Â define: #profileBio as: String;
>> Â Â Â Â Â Â Â Â Â "define: #createdAt as: String;"
>> Â Â Â Â Â Â Â Â Â yourself.
>>
>> ===
>>
>> What I'm missing? And more importantly: how can I debug the message,
>> so I can asign the proper non nil object as receiver of #idDataField ?
>>
>> Finally (for now ;-) ), the ReStore manual has been and important
>> learning resource. Are you the author? And if so, would you be so
>> kind to upload the Word source code to the Documentation/ folder in
>> the repository under a permissive license that allow at least some
>> format changes? We would like to add some table of contents and
>> translate it to other formats, as we have done before with other
>> free/libre cultural works (see [1] [2]).
>>
>> [1] https://mutabit.com/repos.fossil/datafem
>> [2] https://mutabit.com/repos.fossil/mapeda/
>>
>> Thanks,
>>
>> Offray
>>
>> On 6/04/22 2:52, John Aspinall wrote:
>>> Hi Offray,
>>>
>>> Youâre correct that ReStore canât store that kind of mixed
>>> dictionary directly. You could store the entire STON text as one
>>> string and reify it on read, though that would mean you canât easily
>>> query on the metadata.
>>>
>>> A compromise solution would be to define objects and slots for the
>>> key data youâd need to query on and a STON string for the residue.
>>> This could be a better solution anyway as excessive/complex
>>> Dictionaries can be a sign that you need to define a new
>>> class/classes. For your particular project this would depend on how
>>> similar the metadata is between tweets - if thereâs not much
>>> commonality then a Dictionary approach may be more appropriate.
>>>
>>> Hope this helps,
>>>
>>> John
>>>
>>>
>>>
>>>> On 5 Apr 2022, at 20:07, Offray Vladimir Luna Cárdenas
>>>> <offray.luna(a)mutabit.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> First of all, despite of being on a non-directly related matter
>>>> with my question, congrats of Pharo 10.
>>>>
>>>> We (as now we have 2 active Smalltalkers in my country... Yay!) are
>>>> creating a civic tech project with Pharo/Lepiter and we would like
>>>> to store some Tweet metadata coming from Nitter[1]. As we're
>>>> dealing with the differences between the official Twitter API and
>>>> the unofficial Nitter one, we put the metadata we need in a
>>>> dictionary that has several kinds of objects, from ordered
>>>> collections to other dictionaries.
>>>>
>>>> [1] https://nitter.net/about
>>>>
>>>> Currently if we serialize a Tweet object in STON, we get this:
>>>>
>>>> Tweet { #created : 'Tue, 05 Apr 2022 12:37:56 GMT', #text : '
>>>>
>>>> [ANN] Pharo 10 Released: pharo.org/news/pharo10-releaâ¦
>>>> <https://pharo.org/news/pharo10-released>
>>>>
>>>> \n', #id : '1511322244353597443', #user : NitterUser { #userName :
>>>> 'pharoproject', #profileImageUrl : URL [
>>>> 'http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo…'
>>>> ] }, #metadata : { 'queries' : OrderedCollection [ { 'date' :
>>>> DateAndTime [ '2022-04-05T13:36:58.546011-05:00' ], 'parameters' :
>>>> 'https://nitter.42l.fr/pharoproject' } ], 'timelines' : {
>>>> 'pharoproject' : '1511048498703126529' } } }
>>>>
>>>> As you can see, the metadata slot contains a dictionary with mixed
>>>> classes of objects. But I read in the ReStore manual[2] (pg 14):
>>>>
>>>> """
>>>>
>>>> Like other collections, the class of elements for both key and
>>>> value can be any other
>>>> persistent class, and will be the same for all elements of that
>>>> collection (except in the case of
>>>> inheritance).
>>>>
>>>> """
>>>>
>>>> So, is ReStore unable to store metadata dictionaries like the one
>>>> described in the previous STON code? if this is possible, how can I
>>>> define it in the Tweet class>>reStoreDefinition?
>>>>
>>>> For the moment, I'm going to create a explicit "timelines" slot to
>>>> store what was being stored at the #timelines key of the metadata
>>>> dictionary. But, as metadata increases, instead of moving variables
>>>> previously inside of a dictionary as explicit slots of an object, I
>>>> think that having a explicit way of storing dictionaries with
>>>> different kinds of objects, in contrast with only uniform ones,
>>>> would be needed (but I don't know if this is in the design scope of
>>>> ReStore).
>>>>
>>>> BTW, Lepiter has allow us to build a pretty fluent interface to
>>>> browser Twitter/Nitter profiles and messages. Here it is how such
>>>> UI looks for browsing last @pharoproject tweets:
>>>>
>>>> https://i.imgur.com/bxFze1g.png
>>>>
>>>> Any help on how to use ReStore in storing mixed dictionaries is
>>>> appreciated.
>>>>
>>>> Thanks,
>>>>
>>>> Offray
>>>>
>>>
>
April 7, 2022
Re: PharoJS mobile development
by Noury Bouraqadi
Yes indeed, this is a mobile app developed using PharoJS.
During tests, the app is run in a web browser.
For production, PharoJS exports a JS file which is then fed into the Crodova build process.
Noury
On Apr 6 2022, at 11:23 pm, danhunfeldz(a)mail.com wrote:
> Brain Treats App: Your Daily Dose of Fun Facts! â nootrix (https://nootrix.com/projects/brain-treats-app/)
>
>
> This is a PharoJS app for mobile devices. How do you use Cordova with PharoJS to develop for mobile apps?
April 7, 2022
Re: [ANN] Pharo 10 released!
by Marcus Denker
I added an issue tracker entry as I have no idea where/how to fix itâ¦
PharoLauncher: List Pharo10 as stable #11102
https://github.com/pharo-project/pharo/issues/11102
> On 6 Apr 2022, at 18:48, Steffen Märcker <merkste(a)web.de> wrote:
>
> Congratulations to the new release. That's quite an impressive amount of changes and cleanups. Will the stable version be available in the PharoLauncher soon?
>
> Cheers, Steffen
>
>
> Esteban Lorenzano schrieb am Dienstag, 5. April 2022 12:39:44 (+02:00):
>
> Dear Pharo users and dynamic language lovers:
>
> We have released Pharo version 10 !
>
> Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback.
>
>
>
> Pharo 10 was a short iteration where we focused mainly on stability and enhancement of the environment :
>
> ⢠Massive system cleanup
> â¢
> ⢠gained speed
> ⢠removed dead code
> ⢠removed old/deprecated frameworks (Glamour, GTTools, Spec1)
> ⢠All Remaining tools written using the deprecated frameworks have been rewritten: Dependency Analyser, Critique Browser, and many other small utilities.
> ⢠Modularisation has made a leap, creating correct baselines (project descriptions) for many internal systems, making possible the work and deployment of minimal images.
> ⢠Removing support for the old Bytecode sets and embedded blocks simplified the compiler and language core.
> ⢠As a result, our image size has been reduced by 10% (from 66MB to 58MB)
> ⢠The VM has also improved in several areas: better async I/O support, socket handling, FFI ABI,
> Even being a short iteration, we have closed a massive amount of issues: around 600 issues and 700 pull requests. A more extended changelog can be found at https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo100Chang….
>
> While the technical improvements are significant, still the most impressive fact is that the new code that got in the main Pharo 10 image was contributed by more than 80 people.
>
> Pharo is more than code. It is an exciting project involving a great community.
>
> We thank all the contributors to this release:
>
> Aaron Bieber, Ackerley Tng, Alban Benmouffek, Alejandra Cossio, Aless Hosry, Alexandre Bergel, Aliaksei Syrel, Alistair Grant, Arturo Zambrano, Asbathou Biyalou-Sama, Axel Marlard, Bastien Degardins, Ben Coman, Bernardo Contreras, Bernhard Pieber, Carlo Teixeira, Carlos Lopez, Carolina Hernandez, Christophe Demarey, Clotilde Toullec, Connor Skennerton, Cyril Ferlicot, Dave Mason, David Wickes, Denis Kudriashov, Eric Gade, Erik Stel, Esteban Lorenzano, Evelyn Cusi Lopez, Ezequiel R. Aguerre, Gabriel Omar Cotelli, Geraldine Galindo, Giovanni Corriga, Guille Polito, Himanshu, Jan Bliznicenko, Jaromir Matas, Kasper Ãsterbye, Kausthub Thekke Madathil, Konrad Hinsen, Kurt Kilpela, Luz Paz, Marco Rimoldi, Marcus Denker, MartÃn Dias, Massimo Nocentini, Max Leske, Maximilian-ignacio Willembrinck Santander, Miguel Campero, Milton Mamani Torres, Nahuel Palumbo, Norbert Hartl, Norm Green, Nour Djihan, Noury Bouraqadi, Oleksandr Zaitsev, Pablo Sánchez RodrÃguez, Pablo Tesone, Pavel Krivanek, Pierre Misse-Chanabier, Quentin Ducasse, Raffaello Giulietti, Rakshit, Renaud de Villemeur, Rob Sayers, Roland Bernard, Ronie Salgado, Santiago Bragagnolo, Sean DeNigris, Sebastian Jordan Montt, Soufyane Labsari, Stephan Eggermont, Steven Costiou, Stéphane Ducasse, Sven Van Caekenberghe, Theo Rogliano, Thomas Dupriez, Théo Lanord, Torsten Bergmann, Vincent Blondeau.
>
>
> (If you contributed to Pharo 10 development in any way and we missed your name, please send us an email and we will add you).
>
> Enjoy!
>
> The Pharo Team
>
> Discover Pharo: https://pharo.org/features
>
> Try Pharo: http://pharo.org/download
>
> Learn Pharo: http://pharo.org/documentation
>
> --
> Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.
April 7, 2022
Re: ReStore and storing mixed dictionaries
by John Aspinall
Hi Offray,
Regarding the error, Iâm guessing that ReStore doesnât have a table object for your NitterUser class for some reason. Could you try:
myReStore tableForClass: NitterUser
â¦and check if this is returning nil? If so thereâs an issue with creating the table for the class; you could try stepping through
NitterUser reStoreDefinition asTableIn: myReStore
...to get an idea of whatâs wrong.
If this isnât the issue please let me know.
Regarding the manual, Iâll send this to you by mail.
Cheers.
John
> On 6 Apr 2022, at 19:48, Offray Vladimir Luna Cárdenas <offray.luna(a)mutabit.com> wrote:
>
> Thanks Jhon, it definitively helps.
>
> What I did was to extract some important metadata as slots of the Tweet object and made explicit the authorId, which allows me to trace tweets authorship:
>
> ===
> Tweet>>class #reStoreDefinition
> ^ super reStoreDefinition
> defineAsID: #id;
> define: #text as: String;
> define: #created as: String;
> define: #authorId as: String;
> define: #timelines as: (Dictionary of: String -> String); yourself
>
> ===
> Also I'm going to put in the radar the idea of storing STON strings for metadata residues.
>
> On a related matter, I'm still unable to store properly the NitterUser, which inherits from TwitterUser into SQLite and always get a pre-commit error: "#idDataField was send to nil" when I ran "myNitterUser store". Here is my TwitterUser storing definition:
>
> ===
> TwitterUser>>class #reStoreDefinition
> ^ super reStoreDefinition
> defineAsID: #id;
> define: #userName as: String;
> define: #profileImageUrl as: String;
> define: #profileBio as: String;
> "define: #createdAt as: String;"
> yourself.
>
> ===
>
> What I'm missing? And more importantly: how can I debug the message, so I can asign the proper non nil object as receiver of #idDataField ?
>
> Finally (for now ;-) ), the ReStore manual has been and important learning resource. Are you the author? And if so, would you be so kind to upload the Word source code to the Documentation/ folder in the repository under a permissive license that allow at least some format changes? We would like to add some table of contents and translate it to other formats, as we have done before with other free/libre cultural works (see [1] [2]).
>
> [1] https://mutabit.com/repos.fossil/datafem <https://mutabit.com/repos.fossil/datafem>
> [2] https://mutabit.com/repos.fossil/mapeda/ <https://mutabit.com/repos.fossil/mapeda/>
>
> Thanks,
>
> Offray
> On 6/04/22 2:52, John Aspinall wrote:
>> Hi Offray,
>>
>> Youâre correct that ReStore canât store that kind of mixed dictionary directly. You could store the entire STON text as one string and reify it on read, though that would mean you canât easily query on the metadata.
>>
>> A compromise solution would be to define objects and slots for the key data youâd need to query on and a STON string for the residue. This could be a better solution anyway as excessive/complex Dictionaries can be a sign that you need to define a new class/classes. For your particular project this would depend on how similar the metadata is between tweets - if thereâs not much commonality then a Dictionary approach may be more appropriate.
>>
>> Hope this helps,
>>
>> John
>>
>>
>>
>>> On 5 Apr 2022, at 20:07, Offray Vladimir Luna Cárdenas <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote:
>>>
>>> Hi all,
>>>
>>> First of all, despite of being on a non-directly related matter with my question, congrats of Pharo 10.
>>>
>>> We (as now we have 2 active Smalltalkers in my country... Yay!) are creating a civic tech project with Pharo/Lepiter and we would like to store some Tweet metadata coming from Nitter[1]. As we're dealing with the differences between the official Twitter API and the unofficial Nitter one, we put the metadata we need in a dictionary that has several kinds of objects, from ordered collections to other dictionaries.
>>> [1] https://nitter.net/about <https://nitter.net/about>
>>> Currently if we serialize a Tweet object in STON, we get this:
>>>
>>> Tweet { #created : 'Tue, 05 Apr 2022 12:37:56 GMT', #text : '
>>>
>>> [ANN] Pharo 10 Released: pharo.org/news/pharo10-relea⦠<https://pharo.org/news/pharo10-released>\n', #id : '1511322244353597443', #user : NitterUser { #userName : 'pharoproject', #profileImageUrl : URL [ 'http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo… <http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo…>' ] }, #metadata : { 'queries' : OrderedCollection [ { 'date' : DateAndTime [ '2022-04-05T13:36:58.546011-05:00' ], 'parameters' : 'https://nitter.42l.fr/pharoproject <https://nitter.42l.fr/pharoproject>' } ], 'timelines' : { 'pharoproject' : '1511048498703126529' } } }
>>> As you can see, the metadata slot contains a dictionary with mixed classes of objects. But I read in the ReStore manual[2] (pg 14):
>>>
>>> """
>>>
>>> Like other collections, the class of elements for both key and value can be any other
>>> persistent class, and will be the same for all elements of that collection (except in the case of
>>> inheritance).
>>> """
>>> So, is ReStore unable to store metadata dictionaries like the one described in the previous STON code? if this is possible, how can I define it in the Tweet class>>reStoreDefinition?
>>> For the moment, I'm going to create a explicit "timelines" slot to store what was being stored at the #timelines key of the metadata dictionary. But, as metadata increases, instead of moving variables previously inside of a dictionary as explicit slots of an object, I think that having a explicit way of storing dictionaries with different kinds of objects, in contrast with only uniform ones, would be needed (but I don't know if this is in the design scope of ReStore).
>>>
>>> BTW, Lepiter has allow us to build a pretty fluent interface to browser Twitter/Nitter profiles and messages. Here it is how such UI looks for browsing last @pharoproject tweets:
>>>
>>> https://i.imgur.com/bxFze1g.png <https://i.imgur.com/bxFze1g.png>
>>> Any help on how to use ReStore in storing mixed dictionaries is appreciated.
>>>
>>> Thanks,
>>>
>>> Offray
>>
April 7, 2022
Re: [Pharo-dev] [ANN] Pharo 10 released!
by Esteban Maringolo
Congratulations to the core team and to the whole list of contributors!
It's always good to see Smalltalk moving forward.
Regards!
Esteban A. Maringolo
On Tue, Apr 5, 2022 at 7:40 AM Esteban Lorenzano <estebanlm(a)netc.eu> wrote:
> Dear Pharo users and dynamic language lovers:
>
> We have released Pharo version 10 <https://pharo.org/> !
>
> Pharo is a pure object-oriented programming language and a powerful
> environment, focused on simplicity and immediate feedback.
>
>
> Pharo 10 was a short iteration where we focused mainly on stability and
> enhancement of the environment :
>
>
> - Massive system cleanup
> -
> - gained speed
> - removed dead code
> - removed old/deprecated frameworks (Glamour, GTTools, Spec1)
> - All Remaining tools written using the deprecated frameworks have
> been rewritten: Dependency Analyser, Critique Browser, and many other small
> utilities.
> - Modularisation has made a leap, creating correct baselines (project
> descriptions) for many internal systems, making possible the work and
> deployment of minimal images.
> - Removing support for the old Bytecode sets and embedded blocks
> simplified the compiler and language core.
> - As a result, our image size has been reduced by 10% (from 66MB to
> 58MB)
> - The VM has also improved in several areas: better async I/O support,
> socket handling, FFI ABI,
>
> Even being a short iteration, we have closed a massive amount of issues:
> around 600 issues and 700 pull requests. A more extended changelog can be
> found at
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo100Chang…
> .
>
> While the technical improvements are significant, still the most
> impressive fact is that the new code that got in the main Pharo 10 image
> was contributed by more than 80 people.
>
> Pharo is more than code. It is an exciting project involving a great
> community.
>
> We thank all the contributors to this release:
>
> Aaron Bieber, Ackerley Tng, Alban Benmouffek, Alejandra Cossio, Aless
> Hosry, Alexandre Bergel, Aliaksei Syrel, Alistair Grant, Arturo Zambrano,
> Asbathou Biyalou-Sama, Axel Marlard, Bastien Degardins, Ben Coman, Bernardo
> Contreras, Bernhard Pieber, Carlo Teixeira, Carlos Lopez, Carolina
> Hernandez, Christophe Demarey, Clotilde Toullec, Connor Skennerton, Cyril
> Ferlicot, Dave Mason, David Wickes, Denis Kudriashov, Eric Gade, Erik Stel,
> Esteban Lorenzano, Evelyn Cusi Lopez, Ezequiel R. Aguerre, Gabriel Omar
> Cotelli, Geraldine Galindo, Giovanni Corriga, Guille Polito, Himanshu, Jan
> Bliznicenko, Jaromir Matas, Kasper Ãsterbye, Kausthub Thekke Madathil,
> Konrad Hinsen, Kurt Kilpela, Luz Paz, Marco Rimoldi, Marcus Denker, MartÃn
> Dias, Massimo Nocentini, Max Leske, Maximilian-ignacio Willembrinck
> Santander, Miguel Campero, Milton Mamani Torres, Nahuel Palumbo, Norbert
> Hartl, Norm Green, Nour Djihan, Noury Bouraqadi, Oleksandr Zaitsev, Pablo
> Sánchez RodrÃguez, Pablo Tesone, Pavel Krivanek, Pierre Misse-Chanabier,
> Quentin Ducasse, Raffaello Giulietti, Rakshit, Renaud de Villemeur, Rob
> Sayers, Roland Bernard, Ronie Salgado, Santiago Bragagnolo, Sean DeNigris,
> Sebastian Jordan Montt, Soufyane Labsari, Stephan Eggermont, Steven
> Costiou, Stéphane Ducasse, Sven Van Caekenberghe, Theo Rogliano, Thomas
> Dupriez, Théo Lanord, Torsten Bergmann, Vincent Blondeau.
>
>
> (If you contributed to Pharo 10 development in any way and we missed your
> name, please send us an email and we will add you).
>
> Enjoy!
>
> The Pharo Team
>
> Discover Pharo: https://pharo.org/features
>
> Try Pharo: http://pharo.org/download <https://pharo.org/download>
>
> Learn Pharo: http://pharo.org/documentation
> <https://pharo.org/documentation>
>
April 6, 2022
PharoJS mobile development
by danhunfeldz@mail.com
##### [Brain Treats App: Your Daily Dose of Fun Facts! â nootrix](https://nootrix.com/projects/brain-treats-app/)
This is a PharoJS app for mobile devices. How do you use Cordova with PharoJS to develop for mobile apps?
April 6, 2022
Re: [ANN] Pharo 10 released!
by Norbert Hartl
Congratulations! Iâm happy that finally the image lost some of the deprecated things.
Great work! I could migrate our product today to pharo10 in less than 90 minutes. While all the time went into docker, jenkins and all the infrastructure stuff. Only a single thing I needed to change because my code did not handle Deprecations.
I hope we can keep the release cycle as short as this.
Norbert
> Am 05.04.2022 um 12:41 schrieb Esteban Lorenzano <estebanlm(a)netc.eu>:
>
> 
> Dear Pharo users and dynamic language lovers:
>
> We have released Pharo version 10 !
>
> Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback.
>
>
>
> Pharo 10 was a short iteration where we focused mainly on stability and enhancement of the environment :
>
> Massive system cleanup
> gained speed
> removed dead code
> removed old/deprecated frameworks (Glamour, GTTools, Spec1)
> All Remaining tools written using the deprecated frameworks have been rewritten: Dependency Analyser, Critique Browser, and many other small utilities.
> Modularisation has made a leap, creating correct baselines (project descriptions) for many internal systems, making possible the work and deployment of minimal images.
> Removing support for the old Bytecode sets and embedded blocks simplified the compiler and language core.
> As a result, our image size has been reduced by 10% (from 66MB to 58MB)
> The VM has also improved in several areas: better async I/O support, socket handling, FFI ABI,
> Even being a short iteration, we have closed a massive amount of issues: around 600 issues and 700 pull requests. A more extended changelog can be found at https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo100Chang….
>
> While the technical improvements are significant, still the most impressive fact is that the new code that got in the main Pharo 10 image was contributed by more than 80 people.
>
> Pharo is more than code. It is an exciting project involving a great community.
>
> We thank all the contributors to this release:
>
> Aaron Bieber, Ackerley Tng, Alban Benmouffek, Alejandra Cossio, Aless Hosry, Alexandre Bergel, Aliaksei Syrel, Alistair Grant, Arturo Zambrano, Asbathou Biyalou-Sama, Axel Marlard, Bastien Degardins, Ben Coman, Bernardo Contreras, Bernhard Pieber, Carlo Teixeira, Carlos Lopez, Carolina Hernandez, Christophe Demarey, Clotilde Toullec, Connor Skennerton, Cyril Ferlicot, Dave Mason, David Wickes, Denis Kudriashov, Eric Gade, Erik Stel, Esteban Lorenzano, Evelyn Cusi Lopez, Ezequiel R. Aguerre, Gabriel Omar Cotelli, Geraldine Galindo, Giovanni Corriga, Guille Polito, Himanshu, Jan Bliznicenko, Jaromir Matas, Kasper Ãsterbye, Kausthub Thekke Madathil, Konrad Hinsen, Kurt Kilpela, Luz Paz, Marco Rimoldi, Marcus Denker, MartÃn Dias, Massimo Nocentini, Max Leske, Maximilian-ignacio Willembrinck Santander, Miguel Campero, Milton Mamani Torres, Nahuel Palumbo, Norbert Hartl, Norm Green, Nour Djihan, Noury Bouraqadi, Oleksandr Zaitsev, Pablo Sánchez RodrÃguez, Pablo Tesone, Pavel Krivanek, Pierre Misse-Chanabier, Quentin Ducasse, Raffaello Giulietti, Rakshit, Renaud de Villemeur, Rob Sayers, Roland Bernard, Ronie Salgado, Santiago Bragagnolo, Sean DeNigris, Sebastian Jordan Montt, Soufyane Labsari, Stephan Eggermont, Steven Costiou, Stéphane Ducasse, Sven Van Caekenberghe, Theo Rogliano, Thomas Dupriez, Théo Lanord, Torsten Bergmann, Vincent Blondeau.
>
>
> (If you contributed to Pharo 10 development in any way and we missed your name, please send us an email and we will add you).
>
> Enjoy!
>
> The Pharo Team
>
> Discover Pharo: https://pharo.org/features
>
> Try Pharo: http://pharo.org/download
>
> Learn Pharo: http://pharo.org/documentation
April 6, 2022
Re: ReStore and storing mixed dictionaries
by Offray Vladimir Luna Cárdenas
Thanks Jhon, it definitively helps.
What I did was to extract some important metadata as slots of the Tweet
object and made explicit the authorId, which allows me to trace tweets
authorship:
===
Tweet>>class #reStoreDefinition
^ super reStoreDefinition
   defineAsID: #id;
   define: #text as: String;
   define: #created as: String;
   define: #authorId as: String;
   define: #timelines as: (Dictionary of: String -> String); yourself
===
Also I'm going to put in the radar the idea of storing STON strings for
metadata residues.
On a related matter, I'm still unable to store properly the NitterUser,
which inherits from TwitterUser into SQLite and always get a pre-commit
error: "#idDataField was send to nil" when I ran "myNitterUser store".
Here is my TwitterUser storing definition:
===
TwitterUser>>class #reStoreDefinition
   ^ super reStoreDefinition
         defineAsID: #id;
         define: #userName as: String;
         define: #profileImageUrl as: String;
         define: #profileBio as: String;
         "define: #createdAt as: String;"
         yourself.
===
What I'm missing? And more importantly: how can I debug the message, so
I can asign the proper non nil object as receiver of #idDataField ?
Finally (for now ;-) ), the ReStore manual has been and important
learning resource. Are you the author? And if so, would you be so kind
to upload the Word source code to the Documentation/ folder in the
repository under a permissive license that allow at least some format
changes? We would like to add some table of contents and translate it to
other formats, as we have done before with other free/libre cultural
works (see [1] [2]).
[1] https://mutabit.com/repos.fossil/datafem
[2] https://mutabit.com/repos.fossil/mapeda/
Thanks,
Offray
On 6/04/22 2:52, John Aspinall wrote:
> Hi Offray,
>
> Youâre correct that ReStore canât store that kind of mixed dictionary
> directly. You could store the entire STON text as one string and reify
> it on read, though that would mean you canât easily query on the
> metadata.
>
> A compromise solution would be to define objects and slots for the key
> data youâd need to query on and a STON string for the residue. This
> could be a better solution anyway as excessive/complex Dictionaries
> can be a sign that you need to define a new class/classes. For your
> particular project this would depend on how similar the metadata is
> between tweets - if thereâs not much commonality then a Dictionary
> approach may be more appropriate.
>
> Hope this helps,
>
> John
>
>
>
>> On 5 Apr 2022, at 20:07, Offray Vladimir Luna Cárdenas
>> <offray.luna(a)mutabit.com> wrote:
>>
>> Hi all,
>>
>> First of all, despite of being on a non-directly related matter with
>> my question, congrats of Pharo 10.
>>
>> We (as now we have 2 active Smalltalkers in my country... Yay!) are
>> creating a civic tech project with Pharo/Lepiter and we would like to
>> store some Tweet metadata coming from Nitter[1]. As we're dealing
>> with the differences between the official Twitter API and the
>> unofficial Nitter one, we put the metadata we need in a dictionary
>> that has several kinds of objects, from ordered collections to other
>> dictionaries.
>>
>> [1] https://nitter.net/about
>>
>> Currently if we serialize a Tweet object in STON, we get this:
>>
>> Tweet { #created : 'Tue, 05 Apr 2022 12:37:56 GMT', #text : '
>>
>> [ANN] Pharo 10 Released: pharo.org/news/pharo10-releaâ¦
>> <https://pharo.org/news/pharo10-released>
>>
>> \n', #id : '1511322244353597443', #user : NitterUser { #userName :
>> 'pharoproject', #profileImageUrl : URL [
>> 'http://nitter.42l.fr/pic/pbs.twimg.com/profile_images/541743734/icone-pharo…'
>> ] }, #metadata : { 'queries' : OrderedCollection [ { 'date' :
>> DateAndTime [ '2022-04-05T13:36:58.546011-05:00' ], 'parameters' :
>> 'https://nitter.42l.fr/pharoproject' } ], 'timelines' : {
>> 'pharoproject' : '1511048498703126529' } } }
>>
>> As you can see, the metadata slot contains a dictionary with mixed
>> classes of objects. But I read in the ReStore manual[2] (pg 14):
>>
>> """
>>
>> Like other collections, the class of elements for both key and value
>> can be any other
>> persistent class, and will be the same for all elements of that
>> collection (except in the case of
>> inheritance).
>>
>> """
>>
>> So, is ReStore unable to store metadata dictionaries like the one
>> described in the previous STON code? if this is possible, how can I
>> define it in the Tweet class>>reStoreDefinition?
>>
>> For the moment, I'm going to create a explicit "timelines" slot to
>> store what was being stored at the #timelines key of the metadata
>> dictionary. But, as metadata increases, instead of moving variables
>> previously inside of a dictionary as explicit slots of an object, I
>> think that having a explicit way of storing dictionaries with
>> different kinds of objects, in contrast with only uniform ones, would
>> be needed (but I don't know if this is in the design scope of ReStore).
>>
>> BTW, Lepiter has allow us to build a pretty fluent interface to
>> browser Twitter/Nitter profiles and messages. Here it is how such UI
>> looks for browsing last @pharoproject tweets:
>>
>> https://i.imgur.com/bxFze1g.png
>>
>> Any help on how to use ReStore in storing mixed dictionaries is
>> appreciated.
>>
>> Thanks,
>>
>> Offray
>>
>
April 6, 2022