[Pharo-users] Pharo and SQLite

Jimmie Houchin jlhouchin at gmail.com
Fri Oct 16 00:00:58 EDT 2015

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.



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