symbide 0.3.0 is released!

[basti]

Symbide 0.3.0 is released!
Many new features are waiting to get explored:

The biggest novelty is the introduction of subinputs, which are
defining areas of different parsing and execution behavior. At the
moment there are only three different subinputs:
- Text: any text inside will get to the output unchanged (for the
future text formatting is planned)
- Sympy: Basically the inputs nown from symbide0.2
- Python: Behaving like normal python scripts

Furthermore there is now the possibility to use symbide like an
ordinary python-IDE through using pythonsheets. The big difference in
code is that these scripts are executed using a subprocess rather than
threads.

Some other goodies:
- All executions can now be terminated (needs ctypes for thread
aborting)
- Pretty good error backtracking.
- All images and plots can now be easily saved with right-mouse-click
- Logfiles, running executions, available modules, paths can now be
viewed using the monitor: menu->help->monitor

Also installation has been improved:
You can either go on and just download symbide and run it without any
installation, or you can install it system-wide using setuptools.
(further informations in symbides wiki)
For windows there is also an executable installer available.

Either way symbide now uses the users home directory to save the last
open worksheets and his personal settings.

I hope everyone enjoys this release,
basti

p.s
please give feedback when you tried out Symbide.

[Ivan Iakoupov]

Ok I'll start.
I've just tried running it on WinXP. I followed instructions on this page:
http://www.pygtk.org/downloads.html
(installed all 3 python packages and GTK+ runtime)
Then installed symbide using your new shiny installer.

When I run Symbide-script.py (renamed from Symbide-script.pyw to get
console output) I get:

C:\Python25\Scripts>Symbide-script.py
Traceback (most recent call last):
File "C:\Python25\Scripts\Symbide-script.py", line 8, in <module>
load_entry_point('Symbide==0.3.0', 'gui_scripts', 'Symbide')()
File "C:\Python25\lib\site-packages\pkg_resources.py", line 277, in
load_entry
_point
return get_distribution(dist).load_entry_point(group, name)
File "C:\Python25\lib\site-packages\pkg_resources.py", line 2179, in
load_entr
y_point
return ep.load()
File "C:\Python25\lib\site-packages\pkg_resources.py", line 1912, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "C:\Python25\Lib\site-packages\symbide\__init__.py", line 32, in
<module>

from src.execution.execution_manager import ThreadExecutionManager
as _Threa
dExecutionManager
File
"C:\Python25\Lib\site-packages\symbide\src\execution\execution_manager.py
", line 4, in <module>
from signal import SIGTERM, SIGKILL
ImportError: cannot import name SIGKILL

And it's quite true for Python 2.5.1 I have installed on my system:
>>> import signal
>>> dir(signal)
['NSIG', 'SIGABRT', 'SIGBREAK', 'SIGFPE', 'SIGILL', 'SIGINT', 'SIGSEGV',
'SIGTERM', 'SIG_DFL', 'SIG_IGN', '__doc__', '__name__',
'default_int_handler', 'getsignal', 'signal']

There's no SIGKILL signal. Looks like Windows doesn't support such a thing.

P.S.
I see that you have a much saner setup.py script compared to the one
I've proposed (no voodoo dance with MANIFEST.in for one).

[Sebastian]

Sorry, it's my mistake. I didn't see the following notice in the python
documentation:

>Note that not all systems define the same set of signal names; only
>those names defined by the system are defined by this module.

Could you try just to delete following in execution_manager.py ?

ln4: the import of sigkill

ln141-ln146: the for loop and the surrounding lock

ln162-ln166: the for loop and the surrounding lock

Hopefully then it should run, but since i've no possibility to test it
under windows there's no guaranty.

Did you try Symbide out on Linux too?
However, thanks for testing. It would be great if you could go on
helping me to fix Symbide for windows-users.

basti

[Sebastian]

It's maybe easier to replace the line:

>from signal import SIGTERM, SIGKILL

with

>from signal import SIGTERM
>try:
> from signal import SIGKILL
>except:
> SIGKILL = SIGTERM

basti

[Ivan Iakoupov]

Sebastian wrote:
> Could you try just to delete following in execution_manager.py ?
>
> ln4: the import of sigkill
>
> ln141-ln146: the for loop and the surrounding lock
>
> ln162-ln166: the for loop and the surrounding lock
>

Only commenting out SIGKILL bit and commenting out entire ln6
('ImportError' too) made it possible to start symbide. I.e:

from stopable_thread import StopableThread
from threading import Thread, Lock
from gobject import idle_add
from signal import SIGTERM#, SIGKILL
from time import sleep
#from os import kill

The try: <...> except: <...> workaround for SIGKILL seems to work too.

> Hopefully then it should run, but since i've no possibility to test it
> under windows there's no guaranty.
>

I don't know whether running it through WINE will catch everything, but
it should catch at least something I'd think.

> Did you try Symbide out on Linux too?
>

I plan to do so next time I reboot into it.

> However, thanks for testing. It would be great if you could go on
> helping me to fix Symbide for windows-users

I'll see what I can do.

Also I think there's also something completely unrelated to this
problem. The very first run with no C:\Documents and settings\<my
username>\.symbide directory I get a different error message:

C:\Python25\Scripts>Symbide-script.py
Traceback (most recent call last):
File "C:\Python25\Scripts\Symbide-script.py", line 8, in <module>
load_entry_point('Symbide==0.3.0', 'gui_scripts', 'Symbide')()
File "C:\Python25\lib\site-packages\pkg_resources.py", line 277, in
load_entry
_point
return get_distribution(dist).load_entry_point(group, name)
File "C:\Python25\lib\site-packages\pkg_resources.py", line 2179, in
load_entr
y_point
return ep.load()
File "C:\Python25\lib\site-packages\pkg_resources.py", line 1912, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])

File "C:\Python25\Lib\site-packages\symbide\__init__.py", line 29, in
<module>

SettingManager = _SettingManager()
File "C:\Python25\Lib\site-packages\symbide\settingmanager.py", line
18, in __
init__
self.load()
File "C:\Python25\Lib\site-packages\symbide\settingmanager.py", line
33, in lo
ad
getattr(self, 'load'+name)()
File "C:\Python25\Lib\site-packages\symbide\settingmanager.py", line
46, in lo
adPaths
PATHS.update(self.getPaths(path))
File "C:\Python25\Lib\site-packages\symbide\settingmanager.py", line
213, in g
etPaths
userpath = self._ensureUserPath(buf)
File "C:\Python25\Lib\site-packages\symbide\settingmanager.py", line
184, in _
ensureUserPath
for i in os.listdir(copypath):
WindowsError: [Error 3] The system cannot find the path specified:
'C:\\Python25
\\lib\\site-packages\\symbide\\temp\\log\\executor/*.*'

On the 3rd run (not that it has much importance) I got:

C:\Python25\Scripts>Symbide-script.py
Traceback (most recent call last):
File "C:\Python25\Scripts\Symbide-script.py", line 8, in <module>
load_entry_point('Symbide==0.3.0', 'gui_scripts', 'Symbide')()

File "C:\Python25\Lib\site-packages\symbide\Symbide.py", line 13, in run
window.run()
File "C:\Python25\Lib\site-packages\symbide\src\widgets\window.py",
line 63, i
n run
m = MainWindow()
File "C:\Python25\Lib\site-packages\symbide\src\widgets\window.py",
line 31, i
n __init__
children = Notebook(self), MainToolbar(self), MainMenu(self)
File "C:\Python25\Lib\site-packages\symbide\src\widgets\notebook.py",
line 37,
in __init__
self.restoreSheets()
File "C:\Python25\Lib\site-packages\symbide\src\widgets\notebook.py",
line 347
, in restoreSheets
if
os.path.samefile(os.path.dirname(path),PATHS['stored_worksheets'][0]):
AttributeError: 'module' object has no attribute 'samefile'

Python docs for os.path.samefile say:
"Availability: Macintosh, Unix."

[Sebastian]

Ivan Iakoupov schrieb:

For the second problem, I would suggest the following solution:

insert the following into notebook.py:

ln[9]:
>try:
> from os.path import samefile
>except:
> samefile = lambda x, y: os.path.normpath(x)==os.path.normpath(y)

ln[347]:
change "os.path.samefile" to "samefile"

the other problem is a bit weird. did you have to add the folder
".symbide" to your home directory on your own? or was it later created
by symbide?

[Ivan Iakoupov]

Sebastian wrote:
> For the second problem, I would suggest the following solution:
>
> insert the following into notebook.py:
>
> ln[9]:
> >try:
> > from os.path import samefile
> >except:
> > samefile = lambda x, y: os.path.normpath(x)==os.path.normpath(y)
>
> ln[347]:
> change "os.path.samefile" to "samefile"
>
>

Seems to work now.

> the other problem is a bit weird. did you have to add the folder
> ".symbide" to your home directory on your own? or was it later created
> by symbide?
>

It does create the '.symbide' folder itself. Also I noticed that directory

C:\Python25\Lib\site-packages\symbide\temp\log\executor

which it tries to copy from doesn't exist. There's only

C:\Python25\Lib\site-packages\symbide\temp\log

with a single file 'INFO' in it.

I also checked with the tarball and it's the same picture. (While the
SVN does have that needed 'executor' directory)

[Ivan Iakoupov]

Sebastian wrote:
> For the second problem, I would suggest the following solution:
>
> insert the following into notebook.py:
>
> ln[9]:
> >try:
> > from os.path import samefile
> >except:
> > samefile = lambda x, y: os.path.normpath(x)==os.path.normpath(y)
>
> ln[347]:
> change "os.path.samefile" to "samefile"
>
>

Seems to work now.

> the other problem is a bit weird. did you have to add the folder
> ".symbide" to your home directory on your own? or was it later created
> by symbide?
>

[basti]

Great, you found the reason!
I changed the setup.py and created another installer exe. I uploaded
this new exe to:
http://groups.google.com/group/symbide/web/Symbide-0.3.0.win32.exe.png
(You'll have to delete the extension .png. I had to add it because
google doesn't allow exe files uploaded.)

ps.
I also changed killing of subprocesses, since kill won't work in
windows.

[Ivan Iakoupov]

I needed to download

http://sourceforge.net/projects/pywin32/

to make it run, but now symbide seem to have no problems with being
started. But I have yet to try the application itself :P

I wonder if you can use ctypes for killing processes (to get rid of
pywin32 dependency) as described here:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/347462

(I also tried the 3rd suggestion from the comments and it seems to work too)

[basti]

> to make it run, but now symbide seem to have no problems with being
> started. But I have yet to try the application itself :P

I'm glad it's working now!

> I wonder if you can use ctypes for killing processes (to get rid of
> pywin32 dependency) as described here:
>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/347462

I'll implement both variants and a fallback when nothing else is
working a fallback to:

import os
os.popen('TASKKILL /PID '+str(process.pid)+' /F')

Thanks very much for your help so far! I'll try to release the final
installer when I've fixed one other bug I've found. (Not possible to
kill single threads in menu->monitor)

basti