Closed GoogleCodeExporter closed 9 years ago
Could you try and run this version?
http://chemshapes.googlecode.com/files/CS1_Host_Debug_v0.1.0.zip
It won't run, but this version shows up some more debug information that can
help me identify the issue on your system!
Original comment by hra...@gmail.com
on 9 Apr 2012 at 4:37
Issue 2 has been merged into this issue.
Original comment by hra...@gmail.com
on 9 Apr 2012 at 4:38
[deleted comment]
Here's the info from running the program linked above:
C:\Documents and Settings\Shane\My Documents\Cupcake\CS1_Host_Debug_v0.1.0\CS1_H
ost_Debug_v0.1.0>draft.exe
_MEIPASS2 is NULL
Extracting binaries
Executing self as child with Setting up to run child
Creating child process
Waiting for child process to finish...
_MEIPASS2 is C:/DOCUME~1/Shane/LOCALS~1/Temp/_MEI74282/
Already in the child - running!
manifestpath: C:/DOCUME~1/Shane/LOCALS~1/Temp/_MEI74282/draft.exe.manifest
Activation context created
Activation context activated
C:/DOCUME~1/Shane/LOCALS~1/Temp/_MEI74282/python26.dll
Manipulating evironment
PYTHONPATH=C:/DOCUME~1/Shane/LOCALS~1/Temp/_MEI74282;C:/Documents and Settings/S
hane/My Documents/Cupcake/CS1_Host_Debug_v0.1.0/CS1_Host_Debug_v0.1.0
importing modules from CArchive
extracted iu
extracted struct
extracted archive
Installing import hooks
out01-PYZ.pyz
Running scripts
Traceback (most recent call last):
File "<string>", line 21, in <module>
File "Z:\home\rhradec\dev\chemshapes\trunk\host\pyinstaller\PyInstaller\loader
\iu.py", line 410, in importHook
ImportError: No module named PyQt4.QtCore
RC: -1 from pyi_rth_qt4plugins
OK.
Deactivating activation context
Releasing activation context
Done
Back to parent...
Freeing status for C:\Documents and Settings\Shane\My Documents\Cupcake\CS1_Host
_Debug_v0.1.0\CS1_Host_Debug_v0.1.0\draft.exe
C:\Documents and Settings\Shane\My Documents\Cupcake\CS1_Host_Debug_v0.1.0\CS1_H
ost_Debug_v0.1.0>
Original comment by sgra...@gmail.com
on 9 Apr 2012 at 11:01
Done-- here is the output. Just as a heads up i have a couple of other
python environments installed, could that be an issue?
C:\apps\CS1_Host_Debug_v0.1.0>dir
Volume in drive C is OS
Volume Serial Number is 9A92-66F9
Directory of C:\apps\CS1_Host_Debug_v0.1.0
04/08/2012 09:11 PM <DIR> .
04/08/2012 09:11 PM <DIR> ..
04/08/2012 09:11 PM 7,716,423 draft.exe
04/08/2012 09:11 PM 472 draft.exe.manifest
04/08/2012 09:11 PM <DIR> firmware
04/08/2012 09:11 PM <DIR> meshes
02/10/2012 04:25 AM 1,661,952 PyQt4.QtCore.pyd
02/10/2012 04:36 AM 5,806,080 PyQt4.QtGui.pyd
02/10/2012 04:39 AM 200,192 PyQt4.QtOpenGL.pyd
12/17/2011 02:39 PM 2,471,936 QtCore4.dll
12/17/2011 02:49 PM 8,119,808 QtGui4.dll
12/17/2011 02:51 PM 763,392 QtOpenGL4.dll
04/08/2012 09:11 PM <DIR> shaders
8 File(s) 26,740,255 bytes
5 Dir(s) 119,623,077,888 bytes free
C:\apps\CS1_Host_Debug_v0.1.0>draft.exe
_MEIPASS2 is NULL
Extracting binaries
Executing self as child with Setting up to run child
Creating child process
Waiting for child process to finish...
_MEIPASS2 is C:/DOCUME~1/admin/LOCALS~1/Temp/_MEI35122/
Already in the child - running!
manifestpath: C:/DOCUME~1/admin/LOCALS~1/Temp/_MEI35122/draft.exe.manifest
Activation context created
Activation context activated
C:/DOCUME~1/admin/LOCALS~1/Temp/_MEI35122/python26.dll
Manipulating evironment
PYTHONPATH=C:/DOCUME~1/admin/LOCALS~1/Temp/_MEI35122;C:/apps/CS1_Host_Debug_v0.1
.0
importing modules from CArchive
extracted iu
extracted struct
extracted archive
Installing import hooks
out01-PYZ.pyz
Running scripts
Traceback (most recent call last):
File "<string>", line 21, in <module>
File
"Z:\home\rhradec\dev\chemshapes\trunk\host\pyinstaller\PyInstaller\loader
\iu.py", line 410, in importHook
ImportError: No module named PyQt4.QtCore
RC: -1 from pyi_rth_qt4plugins
OK.
Deactivating activation context
Releasing activation context
Done
Back to parent...
Freeing status for C:\apps\CS1_Host_Debug_v0.1.0\draft.exe
C:\apps\CS1_Host_Debug_v0.1.0>
Original comment by dave.cow...@gmail.com
on 9 Apr 2012 at 11:21
Good... booth of you have the same issue, and it's just a simple searchpath
issue.
I'll fix that asap!
Dave, the other python environments you have on your machine shouldn't matter
since the host executable comes with its own self-contained python environment.
(see the message: "Manipulating environment \n
PYTHONPATH=C:/DOCUME~1/admin/LOCALS~1/Temp/_MEI35122;C:/apps/CS1_Host_Debug_v0.1
.0" - it's altering pythonpath so it won't see any other environment)
And in this case, it's definitely not it!
Original comment by hra...@gmail.com
on 9 Apr 2012 at 5:17
Let us know when you've got another release ready and we'll give it a shot. :)
Original comment by sgra...@gmail.com
on 9 Apr 2012 at 5:38
Ok... not fixed yet, but at least I can reproduce the error now!
It seems whatever it's happen on your systems does also happens if I try to run
the windows version under wine!
I'll let you guys known as soon as I get a new version for you to try!
Original comment by hra...@gmail.com
on 9 Apr 2012 at 9:45
OK... give this one a try:
http://chemshapes.googlecode.com/files/CS1_Host_fix_missing_qt.zip
Original comment by hra...@gmail.com
on 10 Apr 2012 at 2:48
and don't forget to let me known if it fixed!!
Original comment by hra...@gmail.com
on 10 Apr 2012 at 2:49
Works for me now! :)
Original comment by sgra...@gmail.com
on 10 Apr 2012 at 3:17
Cool... although Dave didn't report back yet, I'm going to release a new
official version with this fix and some UI improvements when loading a mesh.
I'll wait Dave to report before closing this issue though...
cheers...
-H
Original comment by hra...@gmail.com
on 10 Apr 2012 at 6:00
Original comment by hra...@gmail.com
on 10 Apr 2012 at 6:19
Ok, more feedback on CS1 version 0.1.2 on windows XP. Executed these steps:
(1)start up. observe exceptions in log portion of screen:
PYTHON EXCEPTION: Traceback (most recent call last):
Tue Apr 10 18:40:19 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 286, in initializeGL
Tue Apr 10 18:40:19 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 547, in makeObject
Tue Apr 10 18:40:19 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\O
penGL.error", line 208, in glCheckError
Tue Apr 10 18:40:19 2012 >> PYTHON EXCEPTION: OpenGL.error
Tue Apr 10 18:40:19 2012 >> PYTHON EXCEPTION: .
Tue Apr 10 18:40:19 2012 >> PYTHON EXCEPTION: GLError
Tue Apr 10 18:40:19 2012 >> PYTHON EXCEPTION: :
Tue Apr 10 18:40:19 2012 >> PYTHON EXCEPTION: GLError( err = 1286,
baseOperation = glGenLists, cArguments = (1,), result = 1L )
(2) open happy.stl-- successful after about 30 seconds.
jog wheel slicing works-- but performance is _very_ slow: about 3 seconds after
jog wheel for screen to update.
(3)print --> print simulation, thickness = 400 micron, slice time =0.5 sec.
simulation worked, but unfortunately cpu was pegged, slices were separated in
time clearly due to cpu limits not timer.
(4) load local file repraptest.stl-- this is a simpler test part i created.
observed errors in console--
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File "", line 143, in
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File "", line 522, in loadGeo
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File "", line 550, in refreshMesh
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File "", line 318, in
printPreviewClicked
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 103, in setUserRenderMode
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 328, in resizeGL
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 312, in initFBO
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
letools.framebuffer", line 102, in set_depth
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\p
yglet.gl.lib_wgl", line 95, in __call__
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: WindowsError
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: :
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: exception: access violation
reading 0x00000000
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: Traceback (most recent call
last):
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 385, in paintGL
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 413, in paintGL_render
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: AttributeError
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: :
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: 'Framebuffer' object has no
attribute 'viewport'
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: Traceback (most recent call
last):
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 385, in paintGL
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 413, in paintGL_render
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: AttributeError
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: :
Tue Apr 10 18:46:26 2012 >> PYTHON EXCEPTION: 'Framebuffer' object has no
attribute 'viewport'
Tue Apr 10 18:46:29 2012 >> PYTHON EXCEPTION: Traceback (most recent call
last):
Tue Apr 10 18:46:29 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 385, in paintGL
Tue Apr 10 18:46:29 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 413, in paintGL_render
Tue Apr 10 18:46:29 2012 >> PYTHON EXCEPTION: AttributeError
Tue Apr 10 18:46:29 2012 >> PYTHON EXCEPTION: :
Tue Apr 10 18:46:29 2012 >> PYTHON EXCEPTION: 'Framebuffer' object has no
attribute 'viewport'
Tue Apr 10 18:47:18 2012 >> PYTHON EXCEPTION: Traceback (most recent call
last):
Tue Apr 10 18:47:18 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 385, in paintGL
Tue Apr 10 18:47:18 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 413, in paintGL_render
Tue Apr 10 18:47:18 2012 >> PYTHON EXCEPTION: AttributeError
Tue Apr 10 18:47:18 2012 >> PYTHON EXCEPTION: :
Tue Apr 10 18:47:18 2012 >> PYTHON EXCEPTION: 'Framebuffer' object has no
attribute 'viewport'
Tue Apr 10 18:47:18 2012 >> PYTHON EXCEPTION: Traceback (most recent call
last):
Tue Apr 10 18:47:18 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 385, in paintGL
Tue Apr 10 18:47:18 2012 >> PYTHON EXCEPTION: File
"Z:\home\rhradec\dev\chemshapes\trunk\host\build\pyi.win32\draft\out01-PYZ.pyz\g
lViewport.context", line 413, in paintGL_render
Tue Apr 10 18:47:18 2012 >> PYTHON EXCEPTION: AttributeError
Tue Apr 10 18:47:18 2012 >> PYTHON EXCEPTION: :
Tue Apr 10 18:47:18 2012 >> PYTHON EXCEPTION: 'Framebuffer' object has no
attribute 'viewport'
app seems hosed at this point.
(5) restart application, ( loads repraptest.stl again, this time object renders
ok
(6) use jog wheel, layers are displayed smoothly and quickly
(7) print --> simulation, 0.5 seconds between layers, 400 micron.
observe same behavior as before-- a single slice that appears to be in the
middle of the object appears, then simulation ends. however no exceptions that
i can see. simulation ran too fast to get a screenshot.
Original comment by dave.cow...@gmail.com
on 10 Apr 2012 at 10:48
here is the stl file that produced problems. it was created by solidworks
Original comment by dave.cow...@gmail.com
on 10 Apr 2012 at 10:49
Attachments:
another test-- loaded the attached stl file ( a test overhang )-- after loading
there were no errors, but nothing displays on screen either.
also attached logs for the entire four examples above.
Original comment by dave.cow...@gmail.com
on 10 Apr 2012 at 10:51
Attachments:
The opengl error above is essentially telling us that your video driver OpenGL
implementation doesn't support display lists, which is a pretty standard thing
and SHOULD be available.
I can't find much info about the Intel mobile express 4 series and the log
shows "OpenGL version: 2.0.0 - Build 7.15.10.4990", which seems like a very
early version of OpenGL.
Have you updated the video driver version lately?
http://www.intel.com/p/en_US/support/detect/graphics
Original comment by hra...@gmail.com
on 11 Apr 2012 at 7:01
Probably been a while, I will see if I can upgrade tonight....
Original comment by dave.cow...@gmail.com
on 11 Apr 2012 at 10:28
ok, updated to 2012 version of intel 4500MD graphics drivers.
in the attached session, i did these steps:
(1) start up ( loaded a model but it did not display-- same as befor the
upgrade)
(2) loaded happy.stl. initial view painted after load, and loading was
slightly faster than last time
(3) tried to use jog wheel to slice-- application froze and did not recover,
had to kill it
do i also need to install OpenGL?
Original comment by dave.cow...@gmail.com
on 11 Apr 2012 at 12:06
Attachments:
No... OpenGL comes with the driver.
it actually went up to: "OpenGL version: 2.1.0 - Build 6.14.10.5402"
but it does complain about the same error, which is starting to make me wonder
you GPU doesn't support displayLists, which sounds reaaaaally odd...
I'll do some more research on it... meanwhile, I'll cook a new "debug" version
for you to run some more tests for me, if that's ok!
Original comment by hra...@gmail.com
on 11 Apr 2012 at 8:08
it wouldn't be surprising-- my laptop is a fairly old dell-- about 2008
vintage. its also an integrated video chipset. thanks for the effort. I
wont have time till the weekend but i have a more recent laptop with win7--
i'll be happy to try it on there too
Original comment by dave.cow...@gmail.com
on 11 Apr 2012 at 8:28
No problem... its actually a good exercise since we want the host to run on the
most available GPUs as possible, including old ones!
That's why we choose OpenGL 2.0 as the minimum, since most old models are
already compatible with it, like yours.
Unfortunatelly not all companies implement the specifications in the same
fashion... some are more clever and don't care about small setup pitfalls in
the code, but others are more "picky"!!
AMD is an example of being much more pick than NVidia... and seems Intel
chipset is even PICKIER than AMD! ;)
It's good that you are here, actually... so I have the opportunity to fix this
in such an early stage in the development... This way, when things are ready,
the host will run flawlessly in lots of configurations!! ;)
by the way, here is a new debug... try it and let me known how it goes!
http://chemshapes.googlecode.com/files/debugVersion_svn_745.zip
-H
Original comment by hra...@gmail.com
on 11 Apr 2012 at 9:16
Glad to help! I will try this tonight...
Original comment by dave.cow...@gmail.com
on 11 Apr 2012 at 10:04
Original comment by hra...@gmail.com
on 11 Apr 2012 at 10:49
Hmm no dice on this one. started up and got plenty of exceptions, plus very odd
"corrupted" display.
only one step was performed: startup.
Original comment by dave.cow...@gmail.com
on 11 Apr 2012 at 11:34
Attachments:
could you try this one now?
http://chemshapes.googlecode.com/files/debugVersion_svn_745b.zip
instead of run draft.exe, double click on runDebugger.cmd!
then send me the log_*.html!
Original comment by hra...@gmail.com
on 12 Apr 2012 at 12:15
done.
Original comment by dave.cow...@gmail.com
on 12 Apr 2012 at 12:20
Attachments:
cool... I got some more data!
could you try this one now?
http://chemshapes.googlecode.com/files/debugVersion_svn_745.zip
Original comment by hra...@gmail.com
on 12 Apr 2012 at 1:38
again, run the "runDebugger.cmd" and send me the log plz!
Original comment by hra...@gmail.com
on 12 Apr 2012 at 1:39
sure n/p here u go...
Original comment by dave.cow...@gmail.com
on 12 Apr 2012 at 2:23
Attachments:
lets see... new one:
http://chemshapes.googlecode.com/files/debugVersion_svn_750.zip
Original comment by hra...@gmail.com
on 12 Apr 2012 at 6:31
sorry it took longer to get to this one
Original comment by dave.cow...@gmail.com
on 12 Apr 2012 at 10:11
Attachments:
ok... one more:
http://chemshapes.googlecode.com/files/debugVersion_svn_751.zip
Original comment by hra...@gmail.com
on 12 Apr 2012 at 10:48
ok this time different results!
(1) opened file. for the first time noticed platform build area bounds, that
wasnt there before, good.
(2) loaded mesh happy.stl. loading took 45 sec.
(3) jog wheel worked, albeit very very slowly
(4)did slice simulation, seemed to work ok, ( again very slowly).
(5) loaded repraptest.stl above, did simulation-- screen went black then nothing
i may need a non-debug of this version to test further-- debut seemed to be
impacting performacne too much. i tried to run draft.exe without the debug
option as in the cmd file-- then it threw lots of exceptions. these are
attached in the smaller version. odd that the debug version didnt have
exceptions but reg vesion did?
Original comment by dave.cow...@gmail.com
on 13 Apr 2012 at 2:08
Attachments:
good!!! finally!
It does make sense that it works in debug mode only, since my fix was done on
the debug error check code, not the non-debug.
The problem is that intel express chipset returns a error code when no error
happened!
I'll fix the non-debug code and send you a new version!
Original comment by hra...@gmail.com
on 13 Apr 2012 at 5:15
here we go:
http://chemshapes.googlecode.com/files/debugVersion_svn_757.zip
Original comment by hra...@gmail.com
on 13 Apr 2012 at 7:34
Sweet! That was easy! ;)
Original comment by dave.cow...@gmail.com
on 13 Apr 2012 at 10:33
LOL!!! Is it working now?? all good? Really?!!??
can you send me a final log just for the record?
thanks Dave!
Original comment by hra...@gmail.com
on 13 Apr 2012 at 3:36
oh duh sorry forgot to attach, i will do that tonight
Original comment by dave.cow...@gmail.com
on 13 Apr 2012 at 4:40
but it did work now? is it fast? (apart from loading a model, which I known is
slow right now)
Original comment by hra...@gmail.com
on 13 Apr 2012 at 4:59
hi, sorry! i meant to send all that stuff-- i think its sitting in a
message window at home thats waiting for the send button. sorry.
here was my experience:
loaded-- and saw the build platform and the 'bounding box' which id not
seen before so that was good.
loaded happy.stl-- it took about 45 seconds to load, and it displayed
the jog wheel did work to show slices, but it was very slow-- probably 3-5
seconds per change.
simulation worked, but slice speed again was about 3-5 seconds per slice,
even with 'time between slices' set to 0.5 sec.
loaded repraptest.stl ( uploaded earlier-- ) this object laoded quickly
with no apparent errors.
the jog wheel sliced much more quickly this time, but still not fluid (
this is where i concluded i needed a non-debug version beause the debug is
impacting performance too much
simulation did a single black screen and then came back-- no slices
displayed. this seems like a different issue, so i think i should try it
again with a non-debug version
Original comment by dave.cow...@gmail.com
on 13 Apr 2012 at 5:39
[deleted comment]
Did you run runDebugger.cmd or draft.exe?
The host runs in non-debug mode if you execute draft.exe.
To force it run in debug mode, you have to run runDebugger.cmd.
Although the zip file is called "debug", it doesn't mean it different from the
official release. It only means it's not an official release!
This latest debug svn757 version should work by just running draft.exe now. If
it's not, then there's still a bug in there that I have to fix!
45 secs to load happy.stl is about right. It was taking 30 secs, but it's
longer now due to the progress bar I've added. I traded speed for ui feedback
to avoid users think it just frooze, while it was actually still loading. I'm
planning on switch the mesh loaders by a c++ version later on, after I make it
fully functional for printing for 2 reasons: Speed and Memory!! The current
loaders are too slow and consume too much memory!
3-5 secs seem to be reaaaally long time for the slicing, if you did run
draft.exe!!
runDebugger.cmd would probably give you that... 3-5 secs for slicing... but
draft.exe should be instantaneous!
I hope this speed was from runDebugger.cmd... because if it wasn't, I'm affraid
your GPU may don't have enough juice to slice at all!! :(
About the models you've uploaded:
* repraptest.stl - loads fine here!
* testoverhang.stl - for some reason, it doesnt load at all. It says it loaded 122 polys, but doesn't show the mesh here. I'm investigating if there's a bug in our STL loader.
Original comment by hra...@gmail.com
on 13 Apr 2012 at 6:07
i ran both. runDebugger.cmd produced the output i described. i tried to
run draft.exe directly-- hoping that would run not in debug mode. it did,
but it threw errors
Original comment by dave.cow...@gmail.com
on 13 Apr 2012 at 7:06
please make a non-debug version of latest-- i'll try it tonight.
Original comment by dave.cow...@gmail.com
on 13 Apr 2012 at 7:06
Theres NO-NON-DEBUG versions, dude... there's only draft.exe and
runDebugger.cmd!
Even the latest one now will come with runDebugger.cmd...
runDebugger.cmd runs draft.exe passing a "debug" argument to it... that's all!
draft.exe will "SWITCH" to debug mode if it finds the "debug" argument.
(runDebugger.cmd)
If the latest draft.exe from
http://chemshapes.googlecode.com/files/debugVersion_svn_757.zip throw up some
errors, I need the log again before do a new release.
make sense?
Original comment by hra...@gmail.com
on 13 Apr 2012 at 7:17
stop shoutiing ;) i guess i wasnt communicating well:
yes i understand... when i run without debug on, i just get the old
behavior, lots of errors.
you had said that the fixes you made only took affect when debug was on--
thus, what i meant when i said "non-debug version" was "please put the
fixes which are enabled when you turn on debug, but are not enabled when i
run without debug, into the version what runs when i do not pass in the
debug flag. That way, when i run without debug enabled, i get full speed
execution that does not break, so i can see how the performance is without
all the debug stuff on too"
Original comment by dave.cow...@gmail.com
on 13 Apr 2012 at 7:46
sorry dude... didn't mean to shout!! :P
>> what i meant when i said "non-debug version" was "please put the
>> fixes which are enabled when you turn on debug, but are not enabled when i
>> run without debug, into the version what runs when i do not pass in the
>> debug flag.
Yeah, I did get that, and that already was in debugVersion_svn_757.zip!
But I guess it didn't work, since you're still getting errors! ;)
The thing is, it's not that simple to fix the non-debug mode, since I need to
find now "were" it's happening. I did fix it in debug mode, but that fix was in
a low-level part of the code.
There's a bunch of non-debug higher-level places that can be throwing that
error, and I need to pin-point now were the faulty one is!
The log from running draft.exe from the latest debugVersion_svn_757.zip will
give me some more clues.
make sense?
Original comment by hra...@gmail.com
on 13 Apr 2012 at 7:56
yep, i understand-- i should be able to run the latest tonight and let you
know.
Original comment by dave.cow...@gmail.com
on 13 Apr 2012 at 8:02
(as a side note i'm a developer in my day job so believe me i know what u
are going through)-- well not exactly i do enterprise java and web not so
much graphics.
Original comment by dave.cow...@gmail.com
on 13 Apr 2012 at 8:03
Original issue reported on code.google.com by
dave.cow...@gmail.com
on 9 Apr 2012 at 12:34