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
