[Pharo-users] Pharo and SQLite

Offray Vladimir Luna Cárdenas offray at riseup.net
Thu Oct 15 18:37:23 EDT 2015


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