[Pharo-users] Pharo and SQLite

Offray Vladimir Luna Cárdenas offray at riseup.net
Fri Oct 16 09:18:08 EDT 2015

Thanks. Any code review or comments are welcomed. No interface now 
between fossil and grafoscopio. I just put all my STON files there, but 
STON + fossil is a combination you could consider also.



On 15/10/15 23:00, Jimmie Houchin wrote:
> Okay, I didn't know if you were referring to Grafoscopio or not. I did 
> not know it would be using Fossil for storage.
> I downloaded and will explore next week.
> Thanks.
> Jimmie
> On 10/15/2015 05:37 PM, Offray Vladimir Luna Cárdenas wrote:
>> Hi Jimmie,
>> My idea is to connect Pharo with the external world, starting from 
>> what I need/know, but also I try to not use every single stuff in 
>> other languages. My main criteria for selecting from other ecosystems 
>> is simplicity. I want to make Pharo compatible with my own history 
>> (which is kind of similar to the ones of many non-pharoers), so that 
>> bridge can be crossed by others.
>> This is the app I'm refering to:
>> http://smalltalkhub.com/#!/~Offray/Grafoscopio
>> Is the one I'm making to finally learn Smalltalk with limited time, 
>> so lots of rookie code everywhere, but works (mostly for me now). 
>> Hopefully I will have more time to learn and improve it. I have some 
>> text I have done using it, with open innovation and open/citizen 
>> science as themes  (only in Spanish) and recently I made a proposal 
>> on how to use/extend it (I have been publicizing it in another thread 
>> but details are on [1])
>> [1] 
>> https://www.newschallenge.org/challenge/data/entries/data-kitchen-frictionless-data-moldable-tools-pocket-infrastructures-permanent-workshops-for-community-empowerment
>> Cheers,
>> Offray
>> On 15/10/15 17:10, Jimmie Houchin wrote:
>>> Hello Offray,
>>> If we didn't have the big push for GitHub. I would love to see a 
>>> Fossil source code interface for Pharo. If we had this we could 
>>> potentially replace SmalltalkHub with something more functional 
>>> almost instantly. This is a big assumption, but possibly correct. 
>>> But since it comes with a web ui it has a start. I just don't know 
>>> what would be involved in making it suitable for a community of 
>>> projects. I just find SmalltalkHub painful. I haven't actually 
>>> started using Fossil yet. Just watched the videos and began reading 
>>> the book and drinking the kool-aid. :)
>>> I do love how pro-active he is being in suggesting big things to 
>>> established products or ideas.
>>> While I am very pro doing as much stuff in Pharo as possible. ie: 
>>> not using every tool out there from other languages, Python, Ruby, etc.
>>> I do think it is a good thing when it comes to things like data 
>>> persistence to be ready to use solutions that help people feel 
>>> comfortable that they could have an exit strategy should Pharo some 
>>> how crash, go crazy, quit working or simply fade away like many 
>>> believe Smalltalk already has. It could make some people a little 
>>> more comfortable in a Pharo solution.
>>> He talks about LibreOffice and what benefits it could have if it 
>>> used SQLite rather than a pile of files for persistency. What if 
>>> Pharo was the app and SQLite the persistency for the document? We 
>>> could do our own office suite or whatever. We would have a portable, 
>>> future proof, application file format that people beyond the 
>>> Pharo/Smalltalk community could feel good about.
>>> Which app of yours are you referring to?
>>> Thanks for your input.
>>> Jimmie
>>> On 10/15/2015 03:49 PM, Offray Vladimir Luna Cárdenas wrote:
>>>> Hi Jimmie,
>>>> Nice to see you exploring bridges between Pharo and the external 
>>>> world (that was my message about how I planned to contribute to 
>>>> pharo) and thanks for the reference about the "Git: just say no" 
>>>> video from Hipp (food for my rants with git possessed friends ;-) ).
>>>> [1] https://www.youtube.com/watch?v=ghtpJnrdgbo
>>>> My app uses fossil for storage and exports documents in plain text 
>>>> using STON[2] format and with this combination I can have a remote 
>>>> storage facility which is also pretty portable (just depending on 
>>>> Pharo and a fossil portable binaries). Because I'm working with 
>>>> documents, STON files can have long text inside, which is treated 
>>>> by fossil like binaries and I had not have the time to explore some 
>>>> Sven's suggestions to make it diff friendly. Also I would like some 
>>>> yaml import export on Pharo (maybe via STON). Pharo + Yaml/STON + 
>>>> Fossil could bring us some kind of free schema, human readable, 
>>>> external and distributed storage system that can talk pretty well 
>>>> with the rest of the world.
>>>> Anyway I just want to point that are more people interested in 
>>>> simple and external persistence using Hipps ideas and products. 
>>>> Maybe fossil + STON can work for you also.
>>>> [2] https://github.com/svenvc/ston/blob/master/ston-paper.md
>>>> Keep us posted,
>>>> Offray
>>>> On 15/10/15 12:58, Jimmie Houchin wrote:
>>>>> Hello,
>>>>> I am working on a project for my wife. I initially thought I would 
>>>>> keep all my data inside Pharo because it is a simple project and 
>>>>> Pharo is great at persistence in the image.
>>>>> But as I pursued the project it felt like I was reinventing the 
>>>>> database. So I thought why am I considering working so hard to 
>>>>> structure my classes and objects in such a way that I am in effect 
>>>>> writing my own database. All of this to avoid using a "real" 
>>>>> database.
>>>>> Part of my projects goals is to keep this project contained. I do 
>>>>> not want to require my wife or whomever I share this with to have 
>>>>> to install anything other than copy or unzip the Pharo folder. No 
>>>>> PostgreSQL or MongoDB installs. Keep it simple.
>>>>> This is a goal I have for a lot of my ideas.
>>>>> In my 20+ years of computing and Internet. I have seen lots of 
>>>>> applications come and go.
>>>>> (and no, I don't have gray hair, even though I have children older 
>>>>> than probably half the people here.)
>>>>> Many years ago, my wife and I made tremendous use out of Apple 
>>>>> Works and Microsoft Works. Apple at home and for me Microsoft at 
>>>>> work. We loved the ease and simplicity we could throw a database 
>>>>> together and just do stuff. It was great. In fact on my work PC I 
>>>>> still use weekly and sometimes daily a database I wrote in 1994. I 
>>>>> am almost at the point that Windows won't run this ancient MSWorks 
>>>>> 4 database. I will have to move my data.
>>>>> Of course these tools aren't the greatest. They have significant 
>>>>> limitations, but despite the limitations they were very empowering.
>>>>> My wife started to attempt something similar in LibreOffice but 
>>>>> LibreOffice wasn't so simple. It was confusing to her. I briefly 
>>>>> looked at LibreOffice but I am not convinced that it is the best 
>>>>> or right tool for the job.
>>>>> So that sent me on an adventure to implement this in Pharo. In my 
>>>>> learning that I don't want to reinvent the database I have 
>>>>> initially settled on using SQLite. SQLite meets my requirements 
>>>>> above. It is embedded in my Pharo app and only requires including 
>>>>> the database file I create. Very portable and easy to install 
>>>>> along with anything else in Pharo.
>>>>> SQLite seems like a very good match and complement to Pharo. A 
>>>>> trusted, reliable, external persistence that is as simple and 
>>>>> portable as is Pharo.
>>>>> Richard Hipp creator of SQLite has several videos describing how 
>>>>> he believes SQLite should be used and should not be used.
>>>>> SQLite: The Database at the Edge of the Network with Dr. Richard Hipp
>>>>> https://www.youtube.com/watch?v=Jib2AmRb_rk
>>>>> 2014 SouthEast LinuxFest - Richard Hipp - SQLite as an Application 
>>>>> File Format
>>>>> https://www.youtube.com/watch?v=8y_ABXwYtuc
>>>>> The videos are inspirational for using SQLite. I like what he 
>>>>> says. I encourage watching. I have watched these and others of his 
>>>>> including his anti-git video.
>>>>> I am not knowledgeable about the use of git in Pharo, but I would 
>>>>> be interested if anybody has considered and knows the pros and 
>>>>> cons of using Fossil instead. I know, it wouldn't get us on 
>>>>> GitHub. I may be the only one. But that isn't a biggie for me.
>>>>> TL;DW (didn't watch)
>>>>> Use SQLite for Application File Format for persistence instead of 
>>>>> a (zipped) pile of files and you get many benefits. Examples in 
>>>>> videos as the wrong way, LibreOffice and git.
>>>>> I think using SQLite like this for Pharo would be an excellent 
>>>>> match. We gain all the benefits of SQLite, transactions, ACID. In 
>>>>> a tool that is nicely (non)licensed, and is used and trusted 
>>>>> generally by most all of the software world.
>>>>> For Pharo this buys us an excellent, simple, equally portable 
>>>>> persistence. It also buys us persistence that is trusted by people 
>>>>> who don't trust the image for their data. This could possible help 
>>>>> with people who explore Pharo but aren't comfortable about image 
>>>>> only. Now of course it won't help the Emacs or Vim, ... people.
>>>>> I am exploring the idea of using Pharo and SQLite for what I would 
>>>>> have previously used Apple/MS Works database for. At first it 
>>>>> would be building the app/project for my wife. And during and 
>>>>> after that project generalize some things to make a better out of 
>>>>> the box solution for like projects.
>>>>> Thoughts, opinions, ideas, wisdom. Any and all appreciated.
>>>>> Thanks.
>>>>> Jimmie

More information about the Pharo-users mailing list