You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(13) |
Dec
(33) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(14) |
Feb
(23) |
Mar
(17) |
Apr
(28) |
May
(22) |
Jun
(45) |
Jul
(18) |
Aug
(35) |
Sep
(12) |
Oct
(2) |
Nov
(14) |
Dec
(1) |
2007 |
Jan
(18) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(26) |
Jun
(7) |
Jul
(7) |
Aug
(15) |
Sep
(14) |
Oct
(25) |
Nov
(37) |
Dec
(3) |
2008 |
Jan
(33) |
Feb
(7) |
Mar
(19) |
Apr
(8) |
May
(2) |
Jun
(5) |
Jul
(4) |
Aug
(13) |
Sep
(26) |
Oct
(40) |
Nov
(77) |
Dec
(19) |
2009 |
Jan
(25) |
Feb
(99) |
Mar
(100) |
Apr
(58) |
May
(62) |
Jun
(69) |
Jul
(90) |
Aug
(56) |
Sep
(48) |
Oct
(93) |
Nov
(80) |
Dec
(93) |
2010 |
Jan
(39) |
Feb
(42) |
Mar
(136) |
Apr
(120) |
May
(189) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(12) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Michel B. <mic...@fr...> - 2010-05-10 04:18:32
|
Joerg Scheurich aka MUFTI <rus...@he...> - Mon, 10 May 2010 10:01:33 +0200 >> >I've got a feeling I couldn't mix and match. If I'm in windows (not cygwin) >> then I can't use gnu make and gcc. So I can't use makefiles. > >> Wrong. You can configure your MS Visual Studio project to use a >> Makefile :). > >Wrong again. MS Visual Studio only supports "nmake" which is somewhat >similar to make, but not compatible to a UNIX Makefile 8-) > Huh ! If you are focused on finest argument, I'm not. Sure it could help to explain all that stuff in details but I don't want to loose the main rationale I'm discussing with Doug : build system is central to our efficiency, and if we could have an unique one (managed under version control :)...) that'd be great. >> If someone adds a file to UNIX/Linux/OSX Makefile then it shall be used >> automatically by the Windows build system ;). > >White_dune uses a funny manual mechanism to handle the problems with the >missing updates of the MS Visual Studio project files: >The MS Visual Studio project files compiles a file named >FilesMissingInWindowsProjects.cpp. This file contains only include commands >eg. > >#include "GroupNode.cpp" >#include "WonderlandModuleExportDialog.cpp" >#include "CattExportDialog.cpp" >#include "NodeImport.cpp" >#include "NodeExport.cpp" > >These files are the last sourcefiles, that have been added to the Makefile >and are missing in the current Windows project files. > >>From time to time, FilesMissingInWindowsProjects.cpp is flushed and the >Files are added manually to the Windows project files. > >But if you use (some of ?) the modern XML-based Windows project files, it >is possible to add sourcefiles to the project files directly... > >so long >MUFTI |
From: Joerg S. a. M. <rus...@he...> - 2010-05-10 04:05:13
|
> >My feeling is that the eventloop should be in the ui section, because > >the event code varies according to the UI. > No, I think the main loop should be shared amongst platform because the > main loop is the logic. Specific event handling functions should > provide cross-platform unity for the main loop to be independent. Noone needs a cross-platform mainloop. Usually, events or callbacks are enough. Even advanced things (like timers) can be handled with events or callbacks. > >You also get other benefits: > > You can intercept and usefully use rightclicks, middleclicks etc in > >the GUI eventloop rightclicks, middleclick are events and can be e.g. handled with callbacks for events.... so long MUFTI -- Wie Office für Mac behoben werden kann, dokumentiert langsamer erwartet als dass, wie Office für Mac behoben werden kann, zu Öffnen Knowledge Base ID:892959 Revision:2.1 |
From: Joerg S. a. M. <rus...@he...> - 2010-05-10 04:01:40
|
> >I've got a feeling I couldn't mix and match. If I'm in windows (not cygwin) > then I can't use gnu make and gcc. So I can't use makefiles. > Wrong. You can configure your MS Visual Studio project to use a > Makefile :). Wrong again. MS Visual Studio only supports "nmake" which is somewhat similar to make, but not compatible to a UNIX Makefile 8-) > If someone adds a file to UNIX/Linux/OSX Makefile then it shall be used > automatically by the Windows build system ;). White_dune uses a funny manual mechanism to handle the problems with the missing updates of the MS Visual Studio project files: The MS Visual Studio project files compiles a file named FilesMissingInWindowsProjects.cpp. This file contains only include commands eg. #include "GroupNode.cpp" #include "WonderlandModuleExportDialog.cpp" #include "CattExportDialog.cpp" #include "NodeImport.cpp" #include "NodeExport.cpp" These files are the last sourcefiles, that have been added to the Makefile and are missing in the current Windows project files. >From time to time, FilesMissingInWindowsProjects.cpp is flushed and the Files are added manually to the Windows project files. But if you use (some of ?) the modern XML-based Windows project files, it is possible to add sourcefiles to the project files directly... so long MUFTI -- Wie Office für Mac behoben werden kann, dokumentiert langsamer erwartet als dass, wie Office für Mac behoben werden kann, zu Öffnen Knowledge Base ID:892959 Revision:2.1 |
From: Dave J. <dav...@go...> - 2010-05-09 20:16:30
|
On 10 May 2010 00:42, Michel Briand <mic...@fr...> wrote: > > doug sanden <hig...@ho...> - Sat, 8 May 2010 15:08:06 > -0600 > >> >> >>>> >>>> ... 56 GETFIELDDEFS input/EAIEventsIn.c,589 cNode=5 >>>> GETFIELDDEFS 5 -> 0x5 0x21f8aa0 >>>> GETFIELDDEFS 5 -> 0x21f8aa0 : _nodeType=76 >>>> of string type Material >>> >>> Nope, I am stuck. >>> >>> Do not know how to get from the given node type 76 (in the above >>> example (of string type Material)) to a some unknown table that >>> contains the field types for that node type, and from there to the >>> field names. >>> >>> Don't even know if such tables exist!! >> > if you're on Linux. Type 'make tags'. Open Emacs and type in scratch > the symbol you're searching for. Or open some source file and move your > cursor under that symbol. > I am obviously not explaining my predicament very well. The EAI code is very dense, esp to someone to whom C is not a primary language, I will have no problem finding things once I know their names. So, given I know that the node type of a node is 76, how do I find out the names of all the fields for that type of node? This is made worse by: The code that is suppose to have done this in the past, no longer works. (SIGSEGV) The code that is supposed to have done this, might never have been tested (pointer arithmetic on structures that seem to have changed) Dave |
From: Michel B. <mic...@fr...> - 2010-05-09 19:42:50
|
doug sanden <hig...@ho...> - Sat, 8 May 2010 15:08:06 -0600 > > >>> >>> ... 56 GETFIELDDEFS input/EAIEventsIn.c,589 cNode=5 >>> GETFIELDDEFS 5 -> 0x5 0x21f8aa0 >>> GETFIELDDEFS 5 -> 0x21f8aa0 : _nodeType=76 >>> of string type Material >> >> Nope, I am stuck. >> >> Do not know how to get from the given node type 76 (in the above >> example (of string type Material)) to a some unknown table that >> contains the field types for that node type, and from there to the >> field names. >> >> Don't even know if such tables exist!! > >A few right-click go-to-definitions in the IDE and I'm in generatedCode.c. >looks like its pumped full of tables. Dave, if you're on Linux. Type 'make tags'. Open Emacs and type in scratch the symbol you're searching for. Or open some source file and move your cursor under that symbol. Then type 'ALT+.' and type ENTER. You'll have to confirm that you want to use the TAGS file from the top level source directory. Then you'll be directed at the symbol. Same think with cscope. Put your cursor at the symbol. Load cscope with ALT-x xscope. Then type 'ALT-x cscope-find-functions-calling-this-function' : you'll be directed at the calling function. cheers, Michel |
From: Michel B. <mic...@fr...> - 2010-05-09 19:38:15
|
doug sanden <hig...@ho...> - Sat, 8 May 2010 17:00:14 -0600 > > >> >>>It abandons makefiles - has it's own workspace and project files (like visual studio). I copied projectfiles_vc9 dirctory to codeblocks_vc9, imported the .sln and tinkered a bit (it needs more info where to search system directories, and explicit list of system libs) >>> >> >> I hope that we could have a common build system someday : the Makefile >> (or whatever) are very important to unify the development across >> platforms. The problem with IDE and "project files" is that it only >> works with that particular tool. >> > >Sorry I was wrong. Codeblocks can use makefiles. >http://www.frozeneskimo.com/electronics/arm-tutorials/adapting-codeblocks-ide-for-arm-development/ > > >I've got a feeling I couldn't mix and match. If I'm in windows (not cygwin) then I can't use gnu make and gcc. So I can't use makefiles. > Wrong. You can configure your MS Visual Studio project to use a Makefile :). >Blender has 3 versions of VC, Cmake, make, pb (powerbuilder?) side by side. I guess they have enough developers to maintain all that. Hugin has cmake and vc. Sure. They have enough developers to handle that burden altogether. We, we don't want to push ourselves in a situation where we have to think about that burden : we want the build system to handle compilation and dependencies automatically. If someone adds a file to UNIX/Linux/OSX Makefile then it shall be used automatically by the Windows build system ;). That's the goal. I don't say that automake/autoconf is the only way to achieve this goal. But, at the moment, it helps ;). Cheers, Michel |
From: Michel B. <mic...@fr...> - 2010-05-09 19:33:22
|
Dave Joubert <dav...@go...> - Sat, 8 May 2010 15:53:32 +0100 >On 8 May 2010 15:01, doug sanden <hig...@ho...> wrote: >> Some refactoring thoughts: >> >> If you're refactoring to make freewrl a library component, with published API >> >> top: UI / gui / windowing layer (glut has a right click drop down menu facility, no file picker) >> middle: initialize context, swapBuffer ????? <<< glut does >> bottom (library): initFreewrl(params), eventloop(), freeFreewrl(), ui_related_API ?????? >> >My feeling is that the eventloop should be in the ui section, because >the event code varies according to the UI. No, I think the main loop should be shared amongst platform because the main loop is the logic. Specific event handling functions should provide cross-platform unity for the main loop to be independent. >You also get other benefits: > You can intercept and usefully use rightclicks, middleclicks etc in >the GUI eventloop That's has to be define in main loop specs. Currently we do not do this. > You can generate pseudo-events via say a network connection Sure. With proper callback functions. Through X11 event feed or through EAI socket. Michel |
From: Dave J. <dav...@go...> - 2010-05-09 14:45:06
|
Still looking for a snippet of code that will get mee from the node type to the field names for that node type........ ============================================================================= The EAI document has drifted, and the following should probably be documented. 1) GETEAINODETYPE 2) GETNODETYPE 1) ============================================================================= OPcode B used to be 'UPDATEROUTING' This OPcode has been removed, and there seems to be no replacement OPcode for UPDATEROUTING However, B has been reused, as follows: ./src/lib/input/EAIHeaders.h:#define GETEAINODETYPE 'B' ./src/lib/input/EAIHeaders.h:#define GETNODETYPE 'k' Documentation for this OPcode can be based on a (newly implemented) test, 56B 5 > handle_EAI-- Data is :56B 5 : EAI_parse_commands:start of while loop, strlen 6 str :56B 5 : EAI - seq number 56 EAI command GETEAINODETYPE (B) strlen 4 ... 56 EAI/CLASS Command returns RE 1273428573.381470 56 Material T1_color RE_EOT Yes, the node T1_color was item 5 (previously requested via a GETNODE T1_color) Yes, it is a Material node. 2) ============================================================================= As I suspected, the code for GETNODETYPE 'k' is broken 56k 5 : EAI_parse_commands:start of while loop, strlen 6 str :56k 5 : EAI - seq number 56 EAI command GETNODETYPE (k) strlen 4 ... 56 (My coded comment: Code using boxptr is suspect. input/EAIEventsIn.c,229 : cNode=5 -> boxptr=5) FreeWRL got a SIGSEGV - can .......... Reading the Java examples, it should just return a single value ============================================================================= Aside: The code used in function handleGETEAINODETYPE is probably a good starting point to write a replacement makeFIELDDEFret (which is broken) The code used in function handleGETEAINODETYPE is probably a good starting point to write a replacement for GETNODETYPE (which is broken) Dave |
From: Michel B. <mic...@fr...> - 2010-05-09 05:28:47
|
Hi all, many texture problems are related to the thread handling in FreeWRL. I'm trying to sort out all that stuff... I'm implementing a new feature that makes all console outputs colored : * please see attached image * all outputs that are called through internal.h macros are colored DEBUG_MSG, DEBUG_* (for all sub components: DEBUG_TEX, DEBUG_RES, ...) TRACE_MSG WARN_MSG ERROR_MSG PERROR_MSG * colors are (excerpt from new code in threads.c) #define FREEWRL_MAX_THREADS 5 static int threads_colors[FREEWRL_MAX_THREADS] = { 32, /* main thread is green */ 36, /* display thread is cyan */ 35, /* parse thread is purple */ 33, /* texture thread is brown */ 34, /* shape thread is blue */ /* red color is reserved for important threading functions */ }; #define FREEWRL_DEFAULT_COLOR 37 /* white */ * this code needs to be reworked with the console code (ConsoleMessage.c) to make it cross-platform * I suggest to write a new macro called USER_MSG which behavior will be to replace calls to ConsoleMessage. Reworking of console on OSX and Windows will benefits from this new approach. * Use case of USER_MSG is to send message to the console window for the user to know about some message * User interactive message (touch sensor or all the like) should be handled differently. Imagine new features like popup menus or dialogs in the 3D window ... Currently this is an experimental feature that will be available to developers only (--with-colored-threads, env FREEWRL_TRACE_THREADS). Comments? Best regards, Michel |
From: doug s. <hig...@ho...> - 2010-05-08 19:00:18
|
> >>It abandons makefiles - has it's own workspace and project files (like visual studio). I copied projectfiles_vc9 dirctory to codeblocks_vc9, imported the .sln and tinkered a bit (it needs more info where to search system directories, and explicit list of system libs) >> > > I hope that we could have a common build system someday : the Makefile > (or whatever) are very important to unify the development across > platforms. The problem with IDE and "project files" is that it only > works with that particular tool. > Sorry I was wrong. Codeblocks can use makefiles. http://www.frozeneskimo.com/electronics/arm-tutorials/adapting-codeblocks-ide-for-arm-development/ I've got a feeling I couldn't mix and match. If I'm in windows (not cygwin) then I can't use gnu make and gcc. So I can't use makefiles. Blender has 3 versions of VC, Cmake, make, pb (powerbuilder?) side by side. I guess they have enough developers to maintain all that. Hugin has cmake and vc. -D _________________________________________________________________ Win a $10,000 shopping spree from Hotmail! Enter now. http://go.microsoft.com/?linkid=9729711 |
From: doug s. <hig...@ho...> - 2010-05-08 17:08:09
|
>> >> ... 56 GETFIELDDEFS input/EAIEventsIn.c,589 cNode=5 >> GETFIELDDEFS 5 -> 0x5 0x21f8aa0 >> GETFIELDDEFS 5 -> 0x21f8aa0 : _nodeType=76 >> of string type Material > > Nope, I am stuck. > > Do not know how to get from the given node type 76 (in the above > example (of string type Material)) to a some unknown table that > contains the field types for that node type, and from there to the > field names. > > Don't even know if such tables exist!! A few right-click go-to-definitions in the IDE and I'm in generatedCode.c. looks like its pumped full of tables. _________________________________________________________________ 30 days of prizes: Hotmail makes your day easier! Enter Now. http://go.microsoft.com/?linkid=9729710 |
From: Dave J. <dav...@go...> - 2010-05-08 16:10:03
|
On 8 May 2010 20:15, Dave Joubert <dav...@go...> wrote: > On 8 May 2010 11:33, Dave Joubert <dav...@go...> wrote: > > I have got it to the stage where it can find the right node, viz > > ... 56 GETFIELDDEFS input/EAIEventsIn.c,589 cNode=5 > GETFIELDDEFS 5 -> 0x5 0x21f8aa0 > GETFIELDDEFS 5 -> 0x21f8aa0 : _nodeType=76 > of string type Material Nope, I am stuck. Do not know how to get from the given node type 76 (in the above example (of string type Material)) to a some unknown table that contains the field types for that node type, and from there to the field names. Don't even know if such tables exist!! Got as far as: src/lib/input/EAIEventsIn.c:576: case GETFIELDDEFS: { src/lib/input/EAIEventsIn.c-577- /* get a list of fields of this node */ ......... src/lib/input/EAIEventsIn.c-589- retint = sscanf(&EAI_BUFFER_CUR,"%d",(int *)(&cNode)); src/lib/input/EAIEventsIn.c-590- printf("GETFIELDDEFS %s,%d cNode=%d\n",__FILE__,__LINE__,cNode) ; src/lib/input/EAIEventsIn.c-591- src/lib/input/EAIEventsIn.c-592- src/lib/input/EAIEventsIn.c-593- if (cNode != 0) { src/lib/input/EAIEventsIn.c:594: nodePtr = getEAINodeFromTable(cNode,-1); src/lib/input/EAIEventsIn.c-595- printf ("GETFIELDDEFS %d -> %p %p\n",cNode , boxptr , nodePtr); src/lib/input/EAIEventsIn.c-596- int tempNodeType = nodePtr->_nodeType; src/lib/input/EAIEventsIn.c-597- printf ("GETFIELDDEFS %d -> %p : _nodeType=%d\n",cNode , nodePtr , tempNodeType); src/lib/input/EAIEventsIn.c-598- printf (" of string type %s\n",stringNodeType(tempNodeType)); src/lib/input/EAIEventsIn.c-599- printf (" of SAIX3D type %d\n",getSAI_X3DNodeType(tempNodeType)); Dave |
From: Dave J. <dav...@go...> - 2010-05-08 15:15:23
|
On 8 May 2010 11:33, Dave Joubert <dav...@go...> wrote: .......... > > (The GETFIELDDEFS part of the EAI protocol is not documented, .......... Apart from not being documented, it was non-functional. It was using an incorrect (old?) node retrieval mechanism, and then doing pointer arithmetic... I have got it to the stage where it can find the right node, viz ... 56 GETFIELDDEFS input/EAIEventsIn.c,589 cNode=5 GETFIELDDEFS 5 -> 0x5 0x21f8aa0 GETFIELDDEFS 5 -> 0x21f8aa0 : _nodeType=76 of string type Material Question now is what should it return ? I found the following fragment of Java AI code that might point to the best thing to do: http://www.xj3d.org/tutorials/general_sai.html decls = node.getFieldDefinitions(); dlen = decls.length; int ftype; int atype; MFNode mfnode; SFNode sfnode; X3DNode[] snodes; for(int j=0; j < dlen; j++) { ftype = decls[j].getFieldType(); atype = decls[j].getAccessType(); if (atype == X3DFieldTypes.INPUT_OUTPUT || atype == X3DFieldTypes.INITIALIZE_ONLY) { Reading this implies that it should return all the field names (exposed or not) in an array of strings. Agreed ? Dave |
From: doug s. <hig...@ho...> - 2010-05-08 12:27:02
|
>> top: UI / gui / windowing layer (glut has a right click drop down menu facility, no file picker) >> middle: initialize context, swapBuffer ????? <<< glut does >> bottom (library): initFreewrl(params), eventloop(), freeFreewrl(), ui_related_API ?????? Sorry I was wrong about swapbuffers. Glut makes you call glutSwapbuffers() at the end of your HandleDisplay if you want to see something besides black screen. >> > My feeling is that the eventloop should be in the ui section, because > the event code varies according to the UI. > You also get other benefits: > You can intercept and usefully use rightclicks, middleclicks etc in > the GUI eventloop > You can generate pseudo-events via say a network connection Glut does this with callbacks. You register callbacks for the following: 1. DisplayFunc - like our EventLoop() function in mainloop.c 2. keyboardFunc 3. SpecialFunc 4. mouseFunc 5. mouseMtionFunc Example main() for glut: int main(int argc,char **argv) { ... glutInit(&argc,argv); glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH |GLUT_ACCUM);//|GLUT_ACCUM); glutCreateWindow("Anaglyph simulator"); ... camera.screenwidth = 450; camera.screenheight = 450; glutReshapeWindow(camera.screenwidth,camera.screenheight); if (fullscreen) glutFullScreen(); glutDisplayFunc(HandleDisplay); glutReshapeFunc(HandleReshape); glutVisibilityFunc(HandleVisibility); glutKeyboardFunc(HandleKeyboard); glutSpecialFunc(HandleSpecialKeyboard); glutMouseFunc(HandleMouse); glutMotionFunc(HandleMouseMotion); <<<<< see example below ... } Example handler definition for glut - you define the handler(below) and register it(above), glut calls it /* Handle mouse motion */ void HandleMouseMotion(int x,int y) { static int xlast=-1,ylast=-1; int dx,dy; dx = x - xlast; dy = y - ylast; if (dx < 0) dx = -1; else if (dx> 0) dx = 1; if (dy < 0) dy = -1; else if (dy> 0) dy = 1; if (currentbutton == GLUT_LEFT_BUTTON) RotateCamera(-dx,dy,0); else if (currentbutton == GLUT_MIDDLE_BUTTON) RotateCamera(0,0,dx); xlast = x; ylast = y; } Let's say you just want to refactor the existing code - no glut, but glut compatible refactoring. Then you'd split some of those handle_aqua handle_xevent functions so the generic part is in HandleMouseMotion,HandleMouse,HandleKeyboard,HanldeSpecial and the platform specific code - and your network pseudo event code - is outside of EventLoop()/mainloop.c, in the UI section for example as you suggest. -D _________________________________________________________________ 30 days of prizes to be won with Hotmail. Enter Here. http://go.microsoft.com/?linkid=9729709 |
From: Dave J. <dav...@go...> - 2010-05-08 10:53:35
|
On 8 May 2010 15:01, doug sanden <hig...@ho...> wrote: > Some refactoring thoughts: > > If you're refactoring to make freewrl a library component, with published API > > top: UI / gui / windowing layer (glut has a right click drop down menu facility, no file picker) > middle: initialize context, swapBuffer ????? <<< glut does > bottom (library): initFreewrl(params), eventloop(), freeFreewrl(), ui_related_API ?????? > My feeling is that the eventloop should be in the ui section, because the event code varies according to the UI. You also get other benefits: You can intercept and usefully use rightclicks, middleclicks etc in the GUI eventloop You can generate pseudo-events via say a network connection Dave |
From: doug s. <hig...@ho...> - 2010-05-08 10:01:10
|
> > Not so much looking for a tool on the programming side, rather a tool > like graphviz that shows the big picture. In the bad old days it would > have been walls covered with code listings sticky-taped to them. > Some refactoring thoughts: If you're refactoring to make freewrl a library component, with published API 1. /ui - motif GUI menu vs statusbarHud.c vs statusbarStub.c There's an interface description near the bottom of statusbarHud.c statusbarStub.c - minimalistic stub implementation statusbarHud.c - implements menu, console output, statusbar in the openGL window 2. glut / freeGlut If you refactor to make it glut usable then you'll likely need to move Swapbuffers outside of the mainloop.c eventloop(), so glut implementations can skip it top: UI / gui / windowing layer (glut has a right click drop down menu facility, no file picker) middle: initialize context, swapBuffer ????? <<< glut does bottom (library): initFreewrl(params), eventloop(), freeFreewrl(), ui_related_API ?????? -D _________________________________________________________________ 30 days of prizes: Hotmail makes your day easier! Enter Now. http://go.microsoft.com/?linkid=9729710 |
From: Dave J. <dav...@go...> - 2010-05-08 06:33:29
|
(This is probably directed primarily at John.) I was making a cosmetic '(int *)' change to src/lib/input/EAIEventsIn.c when it dawned on me that this was an area of the EAI that my external code does not test. (The GETFIELDDEFS part of the EAI protocol is not documented, so was never implemented in my Tcl library; in addition I never needed it.) So, I am writing code on the external Tcl-EAI side as well as checking the code on the C libeai and freewrl itself for GETFIELDDEFS When I am finished, obviously I will then have a short section explaining what the GETFIELDDEFS portion of the EAI protocol does, as well as an example. Main point: Who do I send this documentation to? Who is going to maintain this EAI protocol document in the long term? Larger question: Should all the website documents go into CVS and be maintained that way? Dave |
From: Michel B. <mic...@fr...> - 2010-05-08 04:21:24
|
doug sanden <hig...@ho...> - Fri, 7 May 2010 10:17:32 -0600 > > >I did try CodeBlocks with freewrl. Works pretty good - similar to Visual Studio except no object browser, but does have global search, and click-through to source, and you can right-click on a variable or function name and say go-to-definition or go-to-declaration. > Yes, I hear of CodeBlocks. Nice tool :). >It abandons makefiles - has it's own workspace and project files (like visual studio). I copied projectfiles_vc9 dirctory to codeblocks_vc9, imported the .sln and tinkered a bit (it needs more info where to search system directories, and explicit list of system libs) > I hope that we could have a common build system someday : the Makefile (or whatever) are very important to unify the development across platforms. The problem with IDE and "project files" is that it only works with that particular tool. >Then it builds and runs normally. It has a list of compilers- I stuck with the MSVC. You can click on a compiler warning and it opens the source file and takes you to the line. > >It gets it's platform independence via wxWidgets. > That another good point for it. Personally I keep using Emacs. Since it works on all platforms, uses Makefiles and the like, has some "project viewer" modes, some "code browser and search" modes, and all that you may want :). :^) |
From: Dave J. <dav...@go...> - 2010-05-07 15:54:07
|
On 7 May 2010 18:59, Ian Stakenvicius, Aerobiology Research > I've actually tested this against a few different javascript libraries > (not recently, mind you), and although it hasn't been perfect it has > worked relatively OK. -IF- there is a major change in mozilla's > javascript library offering, then we can always drop back to > spidermonkey (which still works just fine). > > That is good to hear; the situation is better than I thought it was. Dave |
From: Ian S. A. R. <ia...@ae...> - 2010-05-07 13:59:14
|
On 07/05/10 01:13 PM, Dave Joubert wrote: > Here I am thinking of two future possibilities: > 1) A major change in the xulrunner code. > > 2) The possibility of using a different javascript engine. > > I think this is probably easier said than done in C > I've actually tested this against a few different javascript libraries (not recently, mind you), and although it hasn't been perfect it has worked relatively OK. -IF- there is a major change in mozilla's javascript library offering, then we can always drop back to spidermonkey (which still works just fine). |
From: Dave J. <dav...@go...> - 2010-05-07 13:23:36
|
Hi Doug, On 7 May 2010 17:17, doug sanden <hig...@ho...> wrote: > > > I did try CodeBlocks with freewrl. Works pretty good - similar to Visual Studio except no object browser, but does have global search, and click-through to source, and you can right-click on a variable or function name and say go-to-definition or go-to-declaration. Not so much looking for a tool on the programming side, rather a tool like graphviz that shows the big picture. In the bad old days it would have been walls covered with code listings sticky-taped to them. Dave |
From: Dave J. <dav...@go...> - 2010-05-07 13:13:31
|
On 7 May 2010 17:05, Ian Stakenvicius, Aerobiology Research <ia...@ae...> wrote: > On 07/05/10 02:57 AM, Michel Briand wrote: >> Dave Joubert <dav...@go...> - Fri, 7 May 2010 00:52:39 .... >>> d) the main program provided a glue layer between the javascript >>> engine and the library > > For d), javascript is used only to handle the dynamic engine stuffs > within freewrl, so I think that should definitely remain part of the > library. Here I am thinking of two future possibilities: 1) A major change in the xulrunner code. 2) The possibility of using a different javascript engine. I think this is probably easier said than done in C |
From: doug s. <hig...@ho...> - 2010-05-07 12:17:39
|
I did try CodeBlocks with freewrl. Works pretty good - similar to Visual Studio except no object browser, but does have global search, and click-through to source, and you can right-click on a variable or function name and say go-to-definition or go-to-declaration. It abandons makefiles - has it's own workspace and project files (like visual studio). I copied projectfiles_vc9 dirctory to codeblocks_vc9, imported the .sln and tinkered a bit (it needs more info where to search system directories, and explicit list of system libs) Then it builds and runs normally. It has a list of compilers- I stuck with the MSVC. You can click on a compiler warning and it opens the source file and takes you to the line. It gets it's platform independence via wxWidgets. _________________________________________________________________ 30 days of prizes: Hotmail makes your day easier! Enter Now. http://go.microsoft.com/?linkid=9729710 |
From: Ian S. A. R. <ia...@ae...> - 2010-05-07 12:05:17
|
On 07/05/10 02:57 AM, Michel Briand wrote: > Dave Joubert <dav...@go...> - Fri, 7 May 2010 00:52:39 > +0100 > > >> 2010/5/6 Ian Stakenvicius, Aerobiology Research <ia...@ae...>: >> >>> Would it make any sense for the main program (plugin, whatever) to handle >>> setting up the window instead of the library? This way the library would be >>> independent of such things and at worst we just need to have different >>> front-end code for each architecture.. >>> >>> >> Yes, to me it would make sense if: >> >> a) The main program could be written in any language that was capable >> of interfacing to the library >> b) The main program handled setting up the drawing context >> c) The main program handled the eventloop >> d) the main program provided a glue layer between the javascript >> engine and the library >> >> > For the OSX front-end this is just the case. It creates the window and > libFreeWRL uses it. > > The main part is not the window creation but the event handling : this > is tricky. > > But I agree with both it could be a big improvement. > > To make the development a success I'd suggest to think twice before ;). > And to clean up the code before :). > I agree about a) above.. For b) i don't know enough about the specifics of the drawing context, but I would think that it would be better for the library to handle that since the library itself would be handling the manipulation of the drawing context..? For c) if it's just calling the event-loop i would agree here too -- or perhaps we could/should make a version of the current freewrl event loop that just does not loop..? (ie, needs to be called successively). We would need to ensure that timed events still occur, though -- multithreading/callbacks? For d), javascript is used only to handle the dynamic engine stuffs within freewrl, so I think that should definitely remain part of the library. |
From: Joerg S. a. M. <rus...@he...> - 2010-05-07 06:57:14
|
> > I installed CodeViz, it do not patch the gcc compiler, it only installs > > a additional patched one. It really creates graphical call graphs. > Is it worth posting it as a graphic on the FreeWRL site ? May be depend, which function of FreeWRL you want to show. As a example, i tested it with a simple 4 lines function, that calls mainly a other 35 lines function: http://129.69.35.12/dune/Node__Node.gif I have my doubts, if it would make much sense, if you would use it for something like "main()" 8-( so long MUFTI -- Eine Java Methode ist ein Satz Java Aussagen, die innerhalb einer Java Kategorie eingeschlossen werden können. (aus einer FAQ) |