Since 1.0.0 final it's released under GPLv2!
SQLiteStudio is described in details on page:
http://sqlitestudio.one.pl/index.php?act=about
Full ChangeLog:
http://sqlitestudio.one.pl/index.rvt?act=changelog
Screenshots can be found at:
http://sqlitestudio.one.pl/index.php?act=screenshots
Discussing forum is placed at:
http://forum.sqlitestudio.one.pl/
I hope you'll enjoy this software!
Any suggestions, bug reports, comments and ideas are welcome on the
discussing forum (see above), as well as some contributions, like
patches or graphics.
--
Pozdrawiam! (Regards!)
Googie
FYI, when I tried to install this on Windows, I got the error "Error
in Tclkit: couldn't open setup.tcl: no such file or directory".
I tried to download and run the executable, but got a
somewhat puzzling message "invalid command name "1"".
It turns out that the executable was named "sqlitestudio-1.0.0[1].exe"
by Internet Explorer.
And the error occurs with setting treectrl_library in
the "package require treetcl" statement.
That looks like a security/safety problem to me.
Regards,
Arjen
Downloading it first and then run it did work.
I played a bit with it - it sure looks nice, but
my PC got stuck at some point (I had defined a
query first, then defined a table and filled it
and wanted to run the query - then it got stuck.
Not sure if this is the way to reproduce the
probem though).
Regards,
Arjen
> Downloading it first and then run it did work.
> I played a bit with it - it sure looks nice, but
> my PC got stuck at some point (I had defined a
> query first, then defined a table and filled it
> and wanted to run the query - then it got stuck.
> Not sure if this is the way to reproduce the
> probem though).
I'll add it to bugs list and try to reproduce it.
--
Pozdrawiam! (Regards!)
Googie
> FYI, when I tried to install this on Windows, I got the error "Error
> in Tclkit: couldn't open setup.tcl: no such file or directory".
Ah... There was 6 betas before and all unusual problems came out after final
release. Do machines hate me? :/
Back to reality...
Can you give me some details about what's your Windows version and where did
you put sqlitestudio.exe file before executing? (maybe there is some path
problem that I haven't predicted)
--
Pozdrawiam! (Regards!)
Googie
Just don't call anything "final" :)
Regards,
Arjen
> Just don't call anything "final" :)
Ok. I'll release 99 betas and 10 Release Candidates next time, then release
final :)
--
Pozdrawiam! (Regards!)
Googie
No problem, I have been there before. I finally got VMware, but even
so something can slip through.
Here's my setup:
* Windows XP Pro version 2002 SP2
* Ran from: "C:\__DownloadInstallFiles\database"
Eric
> Arjen Markus wrote:
>
>> Just don't call anything "final" :)
>
> Ok. I'll release 99 betas and 10 Release Candidates next time, then
> release final :)
And then you get 109 pre-releases without any reports until you release
"final"... :) I had 48 (yes, fourty-eight) pre-releases and not a single
tester found The Bug until 1.0 came out. Sigh. Well, you get what you pay
for, and I pay my testers squat!
--
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done
"Good thing programmers don't build bridges
[the same way as Kaitzschu writes code]."
--John Kelly in comp.lang.tcl
Looks like someone's using [eval] in a bad way...
(Never ever ever trust filenames to be free of metacharacters. Use {*}
or the [list] command as appropriate.)
Donal.
It's an issue with all wrapped Tcl apps at the moment.
Rename TDK's tclapp.exe to tclapp[.exe and you see similar
results.
As a temporary measure in my own apps, I have a quick check at the
very beginning for [] characters in the executable's filename
which displays a tk_messageBox with a suggestion to remove the []
characters. It's only a rough temporary fix though; a more robust
permanent solution would be better.
Further investigation reveals a badly-written pkgIndex.tcl file, so it
is doing:
package ifneeded foo 1.0 "load [file join $dir foo.dll]"
instead of:
package ifneeded foo 1.0 "load [file join [list $dir] foo.dll]"
(or one of the many variants on both those).
I advise that all package authors should test their code when it is
installed in a directory with a space (or square bracket) in the name,
and if they find any problems, fix them using [list] carefully to wrap
$dir or the value derived from it. (Remember, when you're in quoting
hell, [list] is the road out.)
Donal.
Note that many people wait until a final release before trying a new
version of a product, wanting to get the version with all the fixes in
it. That, of course, results in many problems lying hidden until the
release.
Maybe, instead of 99 betas and 10 release candidates, 110 "final
releases" should be performed - that way people say "wow, this
developer is good! See how fast bugs are fixed!"
Plus "Wow, look at that version number (111.0.0), this must be true r0xx0r
Nth generation software!"
I believe the correct/better variant is:
package ifneeded foo 1.0 [list load [file join $dir foo.dll]]
Double quotes almost always make me nervous.
-- Neil
Perhaps, but it's easier to generalize the other case to handle when the
ifneeded script is more than one command. In other words, I did it that
way for a reason. :-)
Donal.
But my point is that it doesn't work properly:
% proc foo arg { puts "arg = '$arg'" }
% foo "load [file join [list $dir] foo.dll]"
arg = 'load {C:/Program Files/My Documents/}/foo.dll'
vs:
% foo [list load [file join $dir foo.dll]]
arg = 'load {C:/Program Files/My Documents/foo.dll}'
(using a completely invented file path). If multiple commands are really
needed, then there is now lambda:
package ifneeded foo 1.0 [list apply {{} { ...; ... }}]
-- Neil
That's wrong too. (Joke: how many experienced Tclers does it take to
write a [package ifneeded] script?)
package ifneeded foo 1.0 [list apply {dir {
load [file join $dir foo.dll]
uplevel 1 [list source [file join $dir foo.tcl]]
}} $dir]
Donal.
Good call! (We should write a book on this... :)
-- Neil