To include in base, was: [7.4.1]Time zone question

While I understand that the base image should, well, be a base image, it is especially for new users confusing that some functionality is not there when they start using the system.
Off hand, I think of:
AutoComplete
OSTimeSupport
RBSUnitExtensions
RBCodeHighlighting

These packages I ***always*** load when using a new build (with some more of course, but these I am willing to consider less essential for the general community), so what about providing a load script for new users that automatically loads these packages I consider "essential"?

+1

Janko

Rob Vens wrote:
--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Rob Vens escreveu: I think instead looking to increase the number of load scripts 'for new
users' we should see how to improve the parcel manager to help people
find more easily (especially new users) functionality in the packages.


--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/

 Rob Vens escreveu:
OSTimeSupport should not be loadable.  It should already be in there.

BTW.  I am using the TimeSoZone package.  Seems to work fine.  Thanks.

-Carl Gundel
http://www.runbasic.com

I agree with some of the posters who thought that these types of facilities should just be part of the system/IDE in the first place rather than making it easier to find and load them.

In most cases the issue is that the facilities need work before they can be included. RBSUnitExtensions is perhaps the exception there, and I note that we do pre-load it in NC images.

We have looked in the past at including some variation of OSTimeZone, the issue has been instability on some platforms. We are hoping to get these resolved and include it in the next release after 7.6.

Both AutoComplete and RBCodeHighlighting are very valuable, but both of them would, in my opinion, require significant work before they could be included. RBCodeHighlighting in particular requires ExtraEmphases, a quite intrusive set of system changes.

At 11:28 AM 1/5/2008, Rob Vens wrote:

While I understand that the base image should, well, be a base image, it is especially for new users confusing that some functionality is not there when they start using the system.
Off hand, I think of:
AutoComplete
OSTimeSupport
RBSUnitExtensions
RBCodeHighlighting

These packages I ***always*** load when using a new build (with some more of course, but these I am willing to consider less essential for the general community), so what about providing a load script for new users that automatically loads these packages I consider "essential"?

2008/1/5, Carl Gundel <[hidden email] >:

What do I need to do to get my VW application to know what time zone the

computer is set to use?  Shouldn't this be automatic?

Thanks,

-Carl Gundel, author of Liberty BASIC

http://www.libertybasic.com

> Both AutoComplete and RBCodeHighlighting are very valuable, but both of them would, in my opinion, require significant work before they could be included. RBCodeHighlighting in particular requires ExtraEmphases, a quite intrusive set of system changes.

I just noticed that "ExternalWebBrower-Text", which is now part of the
default image, is very intrusive, too.

IMHO an important step towards non-intrusiveness would be to add
explicit code editor view/controller classes instead of
overriding/tweaking ParagraphEditor/TextEditorController.

Hi, everyone!

I would suggest include a ready to use local STORE using SQLite3. A VW without Store is a lake without water. SQLite3 is free and platform independent. Indeed, it's only a dll. And a SQLite3 Store is just a database file. I've been using a local Store in SQLite3 for 3 years without any problem. Frequently, I send the whole file to my Gmail for backup. And I send it to a friend of mine, too, so she can load my codes into her image using Store tools.
ObjectStudio will also benefit from SQLite3 if it would adopt it as a internal database.
It's good enough for use by a single user.
It's a chance for new comers or amateurs to feel the coolness of CST at no cost.

 
Best Regards,

Jim G

Jim Guo wrote: I like this idea.

Is SQLite3 a better choice than PostgreSQL?

Dave

Michael Lucas-Smith wrote:

Dave Stevenson wrote:
> Is SQLite3 a better choice than PostgreSQL?
>
I'm not sure about its ability to scale or its performance, but the lack
of services or installation is a huge bonus. Not to mention, sqlite3 is
so ubiquitous that it actually comes as part of the core on MacOSX.

I'd be interested to know how it performs when you've got a semi-big
repository.

Another stumbling block would be the replicator. Ideally, you want
people to be immediately setup with a store database and a way to
replicate their work to other users and other peoples work to their db.
The replicator can do this, but only once you've leaped over a big
learning curve.

It's certainly possible to get there from where we are now.

Michael

Yes, it's any where. PHP and OpenOffice  use it as well as many software that might even mention using it. I once checked a local Chinese stock charting software to find it contains a SQLite3.dll file.

I don't know how big a database file can grow, I often start with a new one since it's to easy. I create new SQLite3-Store file because I would backup it by emailing (I not a programmer in career, but an amateur), almost at each new publishing, so I want to keep the file less then 20 MB for a quick sending out. The biggest database file I can remember to have use, was, in my early days of using SQLite3 Store, some 50 MB or bigger,  which, split and zipped, took 30 mins to send, attached to email messages.

I have once installed a PostgreSQL and spent some ten hours reading the manual and doing the setups to learn that I can't easily backup my codes since the database was living in a lot of files, on disk C, Windozes. Strong and nice but not for me. 5 second is enough to setup/switch to a new SQLite3 Store database. In fact, it's just:
ExternalDatabaseConnection defaultConnection: #SQLite3Connection.
"ExternalDatabaseConnection defaultConnection inspect."
Store.DbRegistry installDatabaseTables.
Then, just type a new name as environment in popup connect to database dialog and it now works. A new file is made for you in the folder where your image is.

So why a pre-installed one is so good when it's so easy to setup such a Store? Since otherwise many people would never give it a try. I myself never tried to use Store for several years since learning to use VW. I used to think it a HUGE and HARD task and I may just not want it. All wrong.

As to performance concerns, since it serves a single person at no cost, is there really any serious performance issues to concern at all? I've never felt it slow, and it's never crashed. That's all. And a network ability is not needed at all. JUST bring it with me or email it to myself and then use it in any machine I work on.
For big companies, I would think they have their database manager and a local database available, so a ready to use SQLite3 Store in VW is not needed at all. However, it will do no harm, anyway. Just forget about the 400k SQLite3.dll and enjoy the system as before, while all those who have never published their bundles to a Store get excited when they run the next version of CST for first time.
For Cincom, they can benefit from a ready to use database in many aspects, not limited to pure Store. For instance, GLORP would have a real database at hand for anyone to do the tests. And a real database instead of the current internal database for ObjectStudio will mean much more potentials.(I was using it 3 years ago). The SQLite3 package in public Store already works fine. There is no extra work at all but just some efforts,  pure mind-work efforts, need to make.

And if CST will be releasing official Smalltalk Application Installer with SQLite3 Store embed in it, which will install applications deployed in parcels into application image and will update them in time when new version of parcels appear, I can feel that world will be changing. Think about it, just a click on a link to a tiny n KB parcel from a web page, and then the VW Application Installer pop up, and take over all the tasks, to setup a Smalltalk software. And it will be the life-time Smalltalk applications maintainer locally on that machine, every thing gets automatic update now. Imaging that. Should it be what COOL means.

Best Regards,

Jim G

What might be better than Postgres, yet still free, is SQL Server Express.
Its 4 Gb database size cap is still large enough to handle a lot of code. It
is SQL Server, therefore the replicator should work as advertised. (I don't
use it because my customer has several SQL Server licenses in house. And he
wanted to get off Postgres after a fatal crash.)

Because it is essentially SQL Server, you still have the learning curve of a
new dBMS. But it comes with the one tool necessary: SQL Server Management
Studio.


----- Original Message -----
From: "Michael Lucas-Smith" <[hidden email]>
To: "Dave Stevenson" <[hidden email]>
Cc: <[hidden email]>
Sent: Tuesday, January 15, 2008 9:02 PM
Subject: Re: To include in base, was: [7.4.1]Time zone question

I use SQLite3 for my local/personal Store repository on my laptop.  Very
fast and I don't have to deal with the password or any other database
services running on my laptop. It's just a dll or so file. Is available for
windows, Mac and linux.  

I replicate to and from our main repositories often.  It is actually
faster to replicate to the SQLite repository than to a Postgres
repository.  At least that has been my observation.

Also have found that SQLite is alot of fun and easy to use with VW for
other personal applications.

here's a video of Dr. Richard Hipp at Google discussing SQLite;
http://video.google.com/videoplay?docid=-5160435487953918649

http://www.linuxformat.co.uk/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=19

Tim

Michael Lucas-Smith wrote:

So replication works. Did someone say that you can only connect from the
local machine, meaning that replication is the only way to share code
across the LAN (I wouldn't dare hit a db file on a shared drive with
different dlls if it were not designed for that)?

Dave

Tim Hutchison wrote:

I replicate from Postgres to SQLite and back to Postgres using the Store replicate tools.  And I do this across the internet. 

I'm not currently sharing a SQLite db .  I'm using it for my personal / local repository.  
As far if a SQLite db file can be accessed by different dlls, I have no answers or experience with that. One would have to direct that question to the makers. 


Dave Stevenson wrote:

So replication works. Did someone say that you can only connect from the local machine, meaning that replication is the only way to share code across the LAN (I wouldn't dare hit a db file on a shared drive with different dlls if it were not designed for that)?

Dave

Tim Hutchison wrote:

I use SQLite3 for my local/personal Store repository on my laptop.  Very fast and I don't have to deal with the password or any other database services running on my laptop. It's just a dll or so file. Is available for
windows, Mac and linux. I replicate to and from our main repositories often.  It is actually faster to replicate to the SQLite repository than to a Postgres repository.  At least that has been my observation.

Also have found that SQLite is alot of fun and easy to use with VW for other personal applications.
here's a video of Dr. Richard Hipp at Google discussing SQLite;
http://video.google.com/videoplay?docid=-5160435487953918649

http://www.linuxformat.co.uk/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=19

Tim

Michael Lucas-Smith wrote:

Dave Stevenson wrote:

Is SQLite3 a better choice than PostgreSQL?

I'm not sure about its ability to scale or its performance, but the lack of services or installation is a huge bonus. Not to mention, sqlite3 is so ubiquitous that it actually comes as part of the core on MacOSX.

I'd be interested to know how it performs when you've got a semi-big repository.

Another stumbling block would be the replicator. Ideally, you want people to be immediately setup with a store database and a way to replicate their work to other users and other peoples work to their db. The replicator can do this, but only once you've leaped over a big learning curve.

It's certainly possible to get there from where we are now.

Michael

Looks like SQLite works for multiple users by locking the whole file.
Not ideal for speed, and certainly not scalable, but probably fine as a
stopgap way to get started with multiple programmers in VW.
http://www.mail-archive.com/sqlite-users@.../msg18342.html

However, some Unix NFS implementations have bugs in network file
locking, and some people's experience suggests the same might be true of
Windows. So it's possible two people could end up writing the same
database at the same time, causing corruption.
http://www.sqlite.org/whentouse.html

Multiple simultaneous readers would be fine, and there won't be any
performance hit due to serializing the requests, just the normal latency
and bandwidth of accessing files across the network. Given that writes
only happen during publish, and developers can't exactly create
megabytes of code in a day, I doubt there will be a huge risk of
corruption on Windows.

I'd say it makes sense to include SQLite in the download, supported only
for single user use. For any real multi-user development, you need a
machine to act as a server anyway - always on, backed up, etc. - and
installing SQL Server Express or PostgreSQL on it is hardly a major
problem.

Steve
op=modload&name=Sections&file

I am thinking about my home LAN. For some reason, I've always had
trouble setting up PostgreSQL. There seems to be a gap between the
creation of a db and the store table creation code. Thanks to the video
by Aik-Siong Koh at:
        http://askoh.net/misc/visualworks/installPostgreSQL/
I got it working on my XP notebook. But I still have trouble on my
ubuntu box.

Given the potential locking issues, I wouldn't try connecting to the
same SQLite db concurrently. But if I only replicate to the local
machine ("pull" code from other repositories), I think I could use
SQLite. That is, an image on machine A can replicate from machine B to
machine A, and an image on machine B can replicate from machine A to
machine B. Or, maybe I'll just use SQLite on my linux box, and keep the
PostgreSQL instance on my XP notebook (since that's the one I use more
often anyway).

Dave

Steven Kelly wrote:

Also SQLite uses duck typing instead of static typing for defining fields.  Much like Smalltalk.
One can define a field as an integer, but can put a string in the field.  Richard Hip comes from
a dynamic language background (tcl/tk) and likes this approach.  In the Google video, he has
a discussion with someone who disagrees with this approach, but Hip defends this position well.

Google is using SQLite in a lot of their products. Google Gears and Android, come to mind.  Firefox
and Safari are using it.  Thought I saw that there is a virus scanner that uses it, can't remember which one.
  And I think that the latest version of Solaris is using it as well.

Apparently it is being used in ways not traditional to databases.  One that comes to mind is as a file format.
Also as an in memory database.


Jim Guo wrote:

2008/1/16, Michael Lucas-Smith <[hidden email]>:

Dave Stevenson wrote:
> Is SQLite3 a better choice than PostgreSQL?
>
I'm not sure about its ability to scale or its performance, but the lack
of services or installation is a huge bonus. Not to mention, sqlite3 is
so ubiquitous that it actually comes as part of the core on MacOSX.

I'd be interested to know how it performs when you've got a semi-big
repository.

[.....]

Michael

Yes, it's any where. PHP and OpenOffice  use it as well as many software that might even mention using it. I once checked a local Chinese stock charting software to find it contains a SQLite3.dll file.

I don't know how big a database file can grow, I often start with a new one since it's to easy. I create new SQLite3-Store file because I would backup it by emailing (I not a programmer in career, but an amateur), almost at each new publishing, so I want to keep the file less then 20 MB for a quick sending out. The biggest database file I can remember to have use, was, in my early days of using SQLite3 Store, some 50 MB or bigger,  which, split and zipped, took 30 mins to send, attached to email messages.

I have once installed a PostgreSQL and spent some ten hours reading the manual and doing the setups to learn that I can't easily backup my codes since the database was living in a lot of files, on disk C, Windozes. Strong and nice but not for me. 5 second is enough to setup/switch to a new SQLite3 Store database. In fact, it's just:
ExternalDatabaseConnection defaultConnection: #SQLite3Connection.
"ExternalDatabaseConnection defaultConnection inspect."
Store.DbRegistry installDatabaseTables.
Then, just type a new name as environment in popup connect to database dialog and it now works. A new file is made for you in the folder where your image is.

So why a pre-installed one is so good when it's so easy to setup such a Store? Since otherwise many people would never give it a try. I myself never tried to use Store for several years since learning to use VW. I used to think it a HUGE and HARD task and I may just not want it. All wrong.

As to performance concerns, since it serves a single person at no cost, is there really any serious performance issues to concern at all? I've never felt it slow, and it's never crashed. That's all. And a network ability is not needed at all. JUST bring it with me or email it to myself and then use it in any machine I work on.
For big companies, I would think they have their database manager and a local database available, so a ready to use SQLite3 Store in VW is not needed at all. However, it will do no harm, anyway. Just forget about the 400k SQLite3.dll and enjoy the system as before, while all those who have never published their bundles to a Store get excited when they run the next version of CST for first time.
For Cincom, they can benefit from a ready to use database in many aspects, not limited to pure Store. For instance, GLORP would have a real database at hand for anyone to do the tests. And a real database instead of the current internal database for ObjectStudio will mean much more potentials.(I was using it 3 years ago). The SQLite3 package in public Store already works fine. There is no extra work at all but just some efforts,  pure mind-work efforts, need to make.

And if CST will be releasing official Smalltalk Application Installer with SQLite3 Store embed in it, which will install applications deployed in parcels into application image and will update them in time when new version of parcels appear, I can feel that world will be changing. Think about it, just a click on a link to a tiny n KB parcel from a web page, and then the VW Application Installer pop up, and take over all the tasks, to setup a Smalltalk software. And it will be the life-time Smalltalk applications maintainer locally on that machine, every thing gets automatic update now. Imaging that. Should it be what COOL means.

Best Regards,

Jim G

Using SQLite could certainy open possibilities and maybe speed
especially if we can use it through Glorp. I currently setup an Access
database for single user installation through the NSIS installer, and
although significantly faster then Postgres, Access files easily get
corrupted. Using SqlLite through Glorp would give much more flexibility
and might provide a  solutions for things like to copy a Postgresbase
base over to a Oracle using a straight table copy on a SQLLite file.

Reading the limitation page on: http://www.sqlite.org/limits.html 
however I am not so sure if this can be done.

Rgrds,

@+Maarten,

Michael Lucas-Smith a écrit :

Hi all!

Jim Guo wrote:
> Dave Stevenson wrote:
>> Is SQLite3 a better choice than PostgreSQL?

N.B.: I have no direct experience with SQLite and I "maintain"
our postgresql installation for the shared store code repository.

In my opinion an answer to this question depends heavily on
the planned use of the code repository.

As a personal store database, which is also usable offline,
SQLite seems to be quite suitable, since it is small and simple
to use.

PostgreSQL took a huge step forward concerning possible acceptance
in providing an installer for Windows since version 8.1. It still
is a full fledged database without a "plug it into my app" support,
so there are a lot of tweakable parameters. This might be too much
for a single user installation.

For a multi user installation I prefer PostgreSQL. As I see it, the
main advantages compared to SQLite are:
- separate database processes:
  if you break your smalltalk image (which I do so about once a
  week), there is a chance, that a database running in the same
  system process can be affected/damaged.
- multi user:
  - there are no locking issues with the "database file"
  - PostgreSQL scales very well with more users, heavy load
    and more database content

Just my $0.02
  Jan