Hi! I looked up the Win32 i18n API this morning and found a potential way of implementing what you want by hand. In fast what you really need is a way to give a complete frame of glyphs to MultiByteToWideChar. In order to do that you need to iterate thru the string and to find where the last complete glyph stands, and so you have to be able to diferentiate leading bytes and trailing bytes. You can then use GetCPInfoEx to get a CPINFOEX struct containing an array of the leading bytes in a particular codepage. Iterating the glyph of a string then become a very easy task and you just have to keep a simple state of conversion by yourself in the class. (IIRC there may be multiple leading bytes followed by only one trailling byte but as soon as you encounter a trailling byte it must be considered as the last byt of the string, this is how UTF8 works anyway).
Did I misunderstood your needs? (I can't access the cvsweb from work, noos.fr must have broken their f.. proxy once again...). Sebastien ----- Original Message ----- From: "Vincent Caron" <[EMAIL PROTECTED]> To: <ngl-cvs@gna.org> Sent: Thursday, July 04, 2002 5:18 AM Subject: [ngl-cvs] nglStringConv win32 support... > CVS reportCommit from zerodeux 2002/07/03 20:18:44 > > -------------------------------------------------------------------------- ------ > > nglStringConv win32 support > > Important note : this is currently based on MLang, and tries to work around > a bunch of bugs/misdesign issues. You can have a look at the source, it > has actually more comments than code :-/. If you want good NLS support > under win32, you can : > > - define USE_ICONV and link against libiconv (GNU) or libICU (IBM) > - provide me the IMultiLanguage2 include files to see if it is less buggy > (requires IE5 for runtime) > - provide me with the e-mail of an IE developer who did not get insane > after working on those buggy and misdocumented MLang interfaces > - beg MS to provide a real ISO-C99 emulation for its OS and stop > reinventing the wheel squarer > - try another OS, whatever > > > See src/core/win32/nglStringConv_mlang.cpp:Process(). > > 1 file added > Module File name Version > ngl src/core/win32/nglStringConv_mlang.cpp 1.1 > > 15 files modified > Module File name Version > ngl ChangeLog 1.39 >>> 1.40 > ngl libngl.dsp 1.8 >>> 1.9 > ngl examples/conv/conv.cpp 1.2 >>> 1.3 > ngl include/ngl.h 1.6 >>> 1.7 > ngl include/nglConsole.h 1.2 >>> 1.3 > ngl include/nglStringConv.h 1.2 >>> 1.3 > ngl include/ngl_config.h 1.2 >>> 1.3 > ngl src/core/nglBaseApp_shr.cpp 1.6 >>> 1.7 > ngl src/core/nglStringConv_shr.cpp 1.2 >>> 1.3 > ngl src/core/nglString_shr.cpp 1.6 >>> 1.7 > ngl src/core/win32/nglBaseApp.cpp 1.7 >>> 1.8 > ngl src/core/win32/nglConsole.cpp 1.1 >>> 1.2 > ngl src/core/win32/nglStringConv.cpp 1.1 >>> 1.2 > ngl src/core/win32/ngl_win32.h 1.1 >>> 1.2 > ngl src/file/nglPath_shr.cpp 1.18 >>> 1.19 > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > No, I will not fix your computer. > http://thinkgeek.com/sf > > > Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17Q7aF-0007Tr-00 for <[EMAIL PROTECTED]>; Thu, 04 Jul 2002 07:27:47 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 44ACDB747 for <[EMAIL PROTECTED]>; Thu, 4 Jul 2002 16:27:45 +0200 (CEST) Subject: Re: [NGL-devel] Re: [ngl-cvs] nglStringConv win32 support... From: Vincent Caron <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Thu Jul 4 07:28:04 2002 X-Original-Date: 04 Jul 2002 16:27:41 +0200 On Thu, 2002-07-04 at 13:11, Sebastien Metrot wrote: > Hi! > > I looked up the Win32 i18n API this morning and found a potential way of > implementing what you want by hand. > In fast what you really need is a way to give a complete frame of glyphs to > MultiByteToWideChar. In order to do that you need to iterate thru the string > and to find where the last complete glyph stands, and so you have to be able > to diferentiate leading bytes and trailing bytes. Not exactly. I need to now how many input bytes have been processed. If the input buffer terminates with an incomplete multibyte sequence, MLang let me detect it properly. The pb is when the output buffer can't fit the whole conversion, you can't tell how many bytes were processed. What's more, implementing nglStringConv::Process() with MBToWC+WCToMB is no fun. You have to implement 3 cases : - anything -> CP_WCHAR : use MBToWC - CP_WCHAR -> anything : use WCToMB - anything -> anything : use MBToWC -> buffer -> WCToMB Other pb : those functions are working on installed locales, thus only on MS code pages (no ISO and such). While unofficial docs seems to say that Win2K's MBToWC can deal with ISO charsets, I've not tested it. And it's only Win2k. And finally we still have our damn pb : no way to know how many input bytes were processed. > You can then use GetCPInfoEx to get a CPINFOEX struct containing an > array of the leading bytes in a particular codepage. Iterating the > glyph of a string then become a very easy task and you just have to > keep a simple state of conversion by yourself in the class. I don't really catch it. The only solution I see is implementing a codepage-aware mblen(), then when there's a buffer output overflow : - count output glyphs wrt the output codepage, say 'out_glyphs' - find how many bytes make 'out_glyphs' in input buffer wrt the input codepage I prefer the current trick which replays the conversion with a smaller input buffer until it fits the output buffer. Glyph couting is MLang job's after all. The heuristic can be efficient, meaning only one more call to DoConvert() (it currently subs quarters of the input buffer, why not). But this is _already_ globally inefficient whatever we do since we have to re-instantiate the damn conversion object as soon as it encountered an output buffer overflow. Conclusion : - a MBToWC/WCToMB implementation would lead to the same pb as MLang, at least provide some control other the default char (for conversion errors), and is prone to have poor codepage support besides installed codepages on most Windows (I guess the dominant installed base is Win98) - MLang requires IE4 (you can ask someone to upgrade to IE4, but not easily to Win2K/XP). It has its own charset tables (system32/mlang.dat), providing ISO (+Asian charsets). It has an API that is _supposed to be_ efficient and multi-purpose. It seems that the bugs were kept on purpose for compatibility sake (my Win2K is fully service-packed and I have latest IE6). So I'm rather eager to try the MLang2 interface, you never know... Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17QJwf-0001PN-00 for <[EMAIL PROTECTED]>; Thu, 04 Jul 2002 20:39:45 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 255FCB4BE for <[EMAIL PROTECTED]>; Fri, 5 Jul 2002 05:39:47 +0200 (CEST) From: Vincent Caron <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Subject: [NGL-devel] Re: [ngl-cvs] Introducing nglFontBase Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Thu Jul 4 20:40:03 2002 X-Original-Date: 05 Jul 2002 05:39:33 +0200 Please note that now FreeType 2.1.x is needed. Go fetch 2.1.2 : http://sourceforge.net/project/showfiles.php?group_id=3157 Or better, use CVS version : $ cvs -d :pserver:[EMAIL PROTECTED] login passwd: <anonymous> $ cvs -d :pserver:[EMAIL PROTECTED] co freetype2 Warning, builds/win32/visualc/freetype.dsp builds against the DLL version of the CRT as a default (not NGL's default). Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17RgC3-0004Ux-00 for <[EMAIL PROTECTED]>; Mon, 08 Jul 2002 14:37:15 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 7BAE0AFC3 for <[EMAIL PROTECTED]>; Mon, 8 Jul 2002 23:37:13 +0200 (CEST) From: Vincent Caron <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Subject: [NGL-devel] Re: [ngl-cvs] started adding the code from Lorenzo Pastrana for a standard win32 console in ngl. Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Mon Jul 8 14:38:03 2002 X-Original-Date: 08 Jul 2002 23:37:03 +0200 Wow, first patch from Lorenzo, thanks ! Be ready for the maintainer's review. There are a bunch of obvious pb and assorted fixes, please consider them : - don't impose experimental patches to the other developers : don't set the USE_... macro to 1 in a CVS file. Use Alt+F7/clic/clic/clic/define macro. This is why the ngl_config.h macros can be overriden by their NO_* equivalent, for per-user settings. - some parts of code dedicated to the win32 std console are not enclosed by #ifdef USE_...#endif. I understand that the macro is in the .cpp file as a temporary hack, and that it makes the class interface constant (and no dependency nightmare). But init/release code should be compiled only when necessary, making it much easier to see where is the win32 std console specific code. - do C++ : the nglConsole::ThreadProc() has 12 occurences of pThis ! Add a C++ thread entry and just use ThreadProc() as a C hook. - the event loop should plug into the nglBaseApp existing event loop of possible. I don't know if mHCin can be polled like any other handle for instance. Or anything. - I find it very odd that the while() relies on PeekConsoleInput() : this makes a redondant INPUT_RECORD copy with ReadConsoleInput(), and what's worse turns ThreadProc() into an idle CPU cycle eater. - if you want to do threading, do it right : there is an obvious race condition where ThreadProc can access a console instance that can be already destroyed in the main thread. Remember that nglConsole is a singleton and that the user can destroy/replace it at any moment (this is documented as such, and we use it as such). What's worst is that the OnInput() callback will be executed from the polling thread. A message should be passed to the main thread. This patch badly BREAKS things. At least document it. - 'nglString buf' is unused. BTW, please try to avoid those universal names when the variable is used for a specific purpose. Only use 'buffer' or 'index' when it is obvious or when you recycle the variable. Note that 'tmp' or 'temp' is most of the time a bad idea. - 'nglString mLine' : there is already an output buffer known as 'nglString mOutputBuffer'. Would be nicer to call it mInputBuffer, it will be soon used by Unices too (because readline support will be removed). - there a good old ANSI-C function called isprint() that is much clever than any trick to know if a char can be printed out. And what's more, it's locale aware. Maybe the wrong locale, since the console uses the OEM charset, but worth trying anyway. It's already used in nglString::HexDump() and works nice under Linux and Windows. - I recently cleaned up a lot of nglConsole code and made it Unicode ready. Please enclose non-Unicode parts in #ifndef USE_WCHAR...#endif. The nglChar type is NOT 'char'. Just don't expect it. BTW, the win32 std console has support for Unicode. Please be courageous :) - the OutputDebugString() code can be really improved : * detect whether you're attached to a debugger or not (it turns out that I rarely use the debugger, the console is just fine when you're not segfaulting) * spare a Tokenize() when there's no '\n' (only one line). This optimisation can already be seen in src/core/nglLog_shr.cpp:InternalLog() (end of method) * enclose it with #ifdef _DEBUG_...#endif Received: from meeloo.net ([62.4.18.112]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17RgS7-0007DS-00 for <[EMAIL PROTECTED]>; Mon, 08 Jul 2002 14:53:53 -0700 Received: from harry ([10.1.1.4]) by meeloo.net with smtp (Exim 3.35 #1 (Debian)) id 17Rg0n-0000hk-00 for <[EMAIL PROTECTED]>; Mon, 08 Jul 2002 23:25:37 +0200 Message-ID: <[EMAIL PROTECTED]> From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Subject: Re: [NGL-devel] Re: [ngl-cvs] started adding the code from Lorenzo Pastrana for a standard win32 console in ngl. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Mon Jul 8 14:54:03 2002 X-Original-Date: Mon, 8 Jul 2002 23:53:43 +0200 ----- Original Message ----- From: "Vincent Caron" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 08, 2002 11:37 PM Subject: [NGL-devel] Re: [ngl-cvs] started adding the code from Lorenzo Pastrana for a standard win32 console in ngl. > Wow, first patch from Lorenzo, thanks ! > > Be ready for the maintainer's review. There are a bunch of obvious pb > and assorted fixes, please consider them : > > - don't impose experimental patches to the other developers : don't set > the USE_... macro to 1 in a CVS file. Use Alt+F7/clic/clic/clic/define > macro. This is why the ngl_config.h macros can be overriden by their > NO_* equivalent, for per-user settings. > This is my fault, I commited just before going home and forgot to change this... > - some parts of code dedicated to the win32 std console are not enclosed > by #ifdef USE_...#endif. I understand that the macro is in the .cpp file > as a temporary hack, and that it makes the class interface constant (and > no dependency nightmare). But init/release code should be compiled only > when necessary, making it much easier to see where is the win32 std > console specific code. > My fault again... Shouldn't commit when in a hurry... > - do C++ : the nglConsole::ThreadProc() has 12 occurences of pThis ! > Add a C++ thread entry and just use ThreadProc() as a C hook. > Sure, it was a crude adaptation of Lorenzo's code. Still need some work (there is a race condition). > - the event loop should plug into the nglBaseApp existing event loop of > possible. I don't know if mHCin can be polled like any other handle for > instance. Or anything. > There is no such event in win32, sadly... > - I find it very odd that the while() relies on PeekConsoleInput() : > this makes a redondant INPUT_RECORD copy with ReadConsoleInput(), and > what's worse turns ThreadProc() into an idle CPU cycle eater. > I'll have a look, i thing its better to block on the Read... > - if you want to do threading, do it right : there is an obvious race > condition where ThreadProc can access a console instance that can be > already destroyed in the main thread. Remember that nglConsole is a > singleton and that the user can destroy/replace it at any moment (this > is documented as such, and we use it as such). What's worst is that the > OnInput() callback will be executed from the polling thread. A message > should be passed to the main thread. This patch badly BREAKS things. At > least document it. > I know, I should have put red paint everywhere saying this... > - 'nglString buf' is unused. BTW, please try to avoid those universal > names when the variable is used for a specific purpose. Only use > 'buffer' or 'index' when it is obvious or when you recycle the variable. > Note that 'tmp' or 'temp' is most of the time a bad idea. > Argh, ok, i'll stop replying :). > > * detect whether you're attached to a debugger or not (it turns out > that I rarely use the debugger, the console is just fine when you're not > segfaulting) > You're not a win32 developper, and it shows :). I launch from dev studio 99% of my time and i'm pretty sure others do too. Having all in one window is a feature, as is the ability to read it after the execution of the program. I'm not sure I can detect this (it is dynamic and can change in the course of the execution of a program). Using OutputDebugString have very little overhead when the debugger is not connected (not far from 0). Sebastien (MeeLoo) Received: from logic.phpwebhosting.com ([66.33.1.213]) by usw-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17RjFD-0005nX-00 for <[EMAIL PROTECTED]>; Mon, 08 Jul 2002 17:52:44 -0700 Received: (qmail 5413 invoked by uid 508); 9 Jul 2002 00:52:38 -0000 Received: from unknown (HELO wraith) (212.194.3.120) by logic.phpwebhosting.com with SMTP; 9 Jul 2002 00:52:38 -0000 From: "Lorenzo Pastrana" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: RE: [NGL-devel] Re: [ngl-cvs] started adding the code from Lorenzo Pastrana for a standard win32 console in ngl. Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Mon Jul 8 17:53:02 2002 X-Original-Date: Tue, 9 Jul 2002 02:50:32 +0200 > > Wow, first patch from Lorenzo, thanks ! > > Well.. I'm a little confused with this code... it just was 'code-as-you-read' hack, while chatting about text-widgets & consoles width Seb... surely not intended for an instant commit.. ;b Anyway all these comments are relevant... > > Be ready for the maintainer's review. There are a bunch of obvious pb > > and assorted fixes, please consider them : > > > > - don't impose experimental patches to the other developers : don't set > > the USE_... macro to 1 in a CVS file. Use Alt+F7/clic/clic/clic/define > > macro. This is why the ngl_config.h macros can be overriden by their > > NO_* equivalent, for per-user settings. > > > > This is my fault, I commited just before going home and forgot to change > this... > > > - some parts of code dedicated to the win32 std console are not enclosed > > by #ifdef USE_...#endif. I understand that the macro is in the .cpp file > > as a temporary hack, and that it makes the class interface constant (and > > no dependency nightmare). But init/release code should be compiled only > > when necessary, making it much easier to see where is the win32 std > > console specific code. > > > > My fault again... Shouldn't commit when in a hurry... Well I influed on this one I guess.. ;b but better solution comes below.. > > > - do C++ : the nglConsole::ThreadProc() has 12 occurences of pThis ! > > Add a C++ thread entry and just use ThreadProc() as a C hook. > > > > Sure, it was a crude adaptation of Lorenzo's code. Still need some work > (there is a race condition). > > > - the event loop should plug into the nglBaseApp existing event loop of > > possible. I don't know if mHCin can be polled like any other handle for > > instance. Or anything. > > > > There is no such event in win32, sadly... maybe a row of custom messages to work width? :-/ Was thinking about a pure abstract class to formalise app/console relation and a looser dependence on implementation, since I had hard time thinking about how to customzie the loop to be able to poll user input from standard console, and still being complient with the overall design (Pop in/out mechanism)... overloading nglConsole doesn't allow to do sutch a thing. The level of abstraction / implementation is good for customizing console's behaviour but not for the console's UI (unless mHistoryPosition, mHistory, and the Completion method were protected (not private) members but still doesn't solve mutch, see below). > > > - I find it very odd that the while() relies on PeekConsoleInput() : > > this makes a redondant INPUT_RECORD copy with ReadConsoleInput(), and > > what's worse turns ThreadProc() into an idle CPU cycle eater. > > > > I'll have a look, i thing its better to block on the Read... > Works OK on Read... > > > - if you want to do threading, do it right : there is an obvious race > > condition where ThreadProc can access a console instance that can be > > already destroyed in the main thread. Remember that nglConsole is a > > singleton and that the user can destroy/replace it at any moment (this I guess the MAIN problem is here... /* public !! */ nglConsole::nglConsole(bool IsVisible) { // This is a singleton ??? (with a public constructor and no ::Instance() method?) if (App.mpCon) delete App.mpCon; // Here comes the race situation App.mpCon=this; [snip] } This is in the win32 code.. dunno if the above is an enforced policy... /* NOT virtual !! */ nglConsole& nglBaseApp::GetConsole() { if (!mpCon) mpCon = new nglConsole(); // here comes the old std console again return *mpCon; } I guess this is a real "NO-NO-YOU WON'T GET THAT FUNKY CUSTOM CONSOLE" or I'm missing something(feature?)...??? may be better a factory method provided by the subclass (optionnal)... ?? if (!mpCon) { if(pfConsoleFactory)mpCon = pfConsoleFactory(); else mpCon = new nglConsole(); } and a protected constructor for nglConsole (forcing use of nglBaseApp::GetConsole() 'friend') (comment-as-you-read)... the console should just be an interface to talk with (IMHO)... > > is documented as such, and we use it as such). What's worst is that the > > OnInput() callback will be executed from the polling thread. A message > > should be passed to the main thread. This patch badly BREAKS things. At > > least document it. > > > > I know, I should have put red paint everywhere saying this... mmmh.. yeah, code-as-you-read symptom... :-/ > > - I recently cleaned up a lot of nglConsole code and made it Unicode > ready. Please enclose non-Unicode parts in #ifndef USE_WCHAR...#endif. > The nglChar type is NOT 'char'. Just don't expect it. > BTW, the win32 std console has support for Unicode. Please be courageous > :) > (WCHAR NEWBIE) maybe you can point me to some docs? what is the general ngl policy/method for unicode? Cheers.. ;) Lo. Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17RjSL-0000Sy-00 for <[EMAIL PROTECTED]>; Mon, 08 Jul 2002 18:06:17 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 271DDAFC3 for <[EMAIL PROTECTED]>; Tue, 9 Jul 2002 03:06:19 +0200 (CEST) From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Subject: [NGL-devel] Coding conventions Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Mon Jul 8 18:07:02 2002 X-Original-Date: 09 Jul 2002 03:06:06 +0200 The coding conventions are now available online : http://ngl.sourceforge.net/doc.php It might need some update, this is 1 year old and was designed for another project. Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17RkgK-0003sK-00 for <[EMAIL PROTECTED]>; Mon, 08 Jul 2002 19:24:49 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 67930AFC3 for <[EMAIL PROTECTED]>; Tue, 9 Jul 2002 04:24:42 +0200 (CEST) From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Subject: [NGL-devel] NUI manual available online Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Mon Jul 8 19:49:11 2002 X-Original-Date: 09 Jul 2002 04:24:29 +0200 Extracted from current CVS and cross-linked with the NGL documentation : http://ngl.sourceforge.net/doc.php?q=nui Further updates will be automated at release time. Received: from meeloo.net ([62.4.18.112]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17RqXb-0002Jx-00; Tue, 09 Jul 2002 01:40:11 -0700 Received: from harry ([10.1.1.4]) by meeloo.net with smtp (Exim 3.35 #1 (Debian)) id 17Rq6F-0002QY-00; Tue, 09 Jul 2002 10:11:55 +0200 Message-ID: <[EMAIL PROTECTED]> From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>, <ngl-cvs@gna.org> References: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [NGL-devel] Re: [ngl-cvs] Changelog:... Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 9 01:41:03 2002 X-Original-Date: Tue, 9 Jul 2002 10:40:00 +0200 ----- Original Message ----- From: "Vincent Caron" <[EMAIL PROTECTED]> To: <ngl-cvs@gna.org> Sent: Tuesday, July 09, 2002 4:20 AM Subject: [ngl-cvs] Changelog:... > - moved nuiValue specialisations implementation to nuiProperty.cpp Ya une raison que je l'ai laissé dans le .h : ces fonctions sont censées etre inline... On pourais en discuter avec de faire de genre de changement qd meme... Seb Received: from meeloo.net ([62.4.18.112]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17RqaA-0002qs-00; Tue, 09 Jul 2002 01:42:50 -0700 Received: from harry ([10.1.1.4]) by meeloo.net with smtp (Exim 3.35 #1 (Debian)) id 17Rq8r-0002R5-00; Tue, 09 Jul 2002 10:14:37 +0200 Message-ID: <[EMAIL PROTECTED]> From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>, <ngl-cvs@gna.org> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Subject: Re: [NGL-devel] Re: [ngl-cvs] Changelog:... MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 9 01:43:05 2002 X-Original-Date: Tue, 9 Jul 2002 10:42:42 +0200 Woops, was meant to be private... Sorry... Seb ----- Original Message ----- From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, July 09, 2002 10:40 AM Subject: [NGL-devel] Re: [ngl-cvs] Changelog:... > > ----- Original Message ----- > From: "Vincent Caron" <[EMAIL PROTECTED]> > To: <ngl-cvs@gna.org> > Sent: Tuesday, July 09, 2002 4:20 AM > Subject: [ngl-cvs] Changelog:... > > > > - moved nuiValue specialisations implementation to nuiProperty.cpp > > Ya une raison que je l'ai laissé dans le .h : ces fonctions sont censées > etre inline... On pourais en discuter avec de faire de genre de changement > qd meme... > > Seb > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Stuff, things, and much much more. > http://thinkgeek.com/sf > _______________________________________________ > NGL-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/ngl-devel > Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17Rsb3-0001VZ-00 for <[EMAIL PROTECTED]>; Tue, 09 Jul 2002 03:51:53 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 6348EB4C1 for <[EMAIL PROTECTED]>; Tue, 9 Jul 2002 12:51:50 +0200 (CEST) Subject: Re: [NGL-devel] Re: [ngl-cvs] Changelog:... From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Content-Type: multipart/mixed; boundary="=-r1DOTK34rBD8KKgujTAD" X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 9 03:52:02 2002 X-Original-Date: 09 Jul 2002 12:51:47 +0200 --=-r1DOTK34rBD8KKgujTAD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 2002-07-09 at 10:40, Sebastien Metrot wrote: >=20 > > - moved nuiValue specialisations implementation to nuiProperty.cpp >=20 > Ya une raison que je l'ai laiss=E9 dans le .h : ces fonctions sont cens= =E9es > etre inline... On pourais en discuter avec de faire de genre de changemen= t > qd meme... Ah, sorry. Ma politique est d'=E9viter le code dans les .h qd c'est possible (cad hors template). Et l=E0 je vois pas comment on peut gagner en perfs en inlinant ce code : - le SetValue() est p=E9nalis=E9 par l'appel a Changed() - le GetValue() est p=E9nalis=E9 par le nglString::Format() Tiens, je t'ai =E9crit un bench, comme =E7a on sera fix=E9. Je regarderais sous Linux. --=-r1DOTK34rBD8KKgujTAD Content-Disposition: attachment; filename=bench.cpp Content-Transfer-Encoding: quoted-printable Content-Type: text/x-c++; name=bench.cpp; charset=ISO-8859-1 #include "nglApp.h" #include "nuiProperty.h" #define ITER 1000000 #define BENCH(type, value) \ { \ chrono =3D nglTime(); \ type val; \ for (i =3D 0; i < ITER; i++) { \ val.SetValue(value); \ val.GetValue(); \ } \ OUT("Total: %.6f sec\n", double(nglTime() - chrono)); \ } class BenchApp : public nglApp { public: void OnInit() { nglTime chrono; int i; BENCH(nuiInt32, 666); BENCH(nuiFloat, 0.666f); Quit(); } }; nglDeclareApp(BenchApp); --=-r1DOTK34rBD8KKgujTAD-- Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17Rsf1-00023m-00 for <[EMAIL PROTECTED]>; Tue, 09 Jul 2002 03:56:00 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 2873EB4C1 for <[EMAIL PROTECTED]>; Tue, 9 Jul 2002 12:55:58 +0200 (CEST) Subject: Re: [NGL-devel] Re: [ngl-cvs] Changelog:... From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 9 03:57:08 2002 X-Original-Date: 09 Jul 2002 12:55:55 +0200 On Tue, 2002-07-09 at 12:51, Vincent Caron wrote: > Tiens, je t'ai =E9crit un bench, comme =E7a on sera fix=E9. Je regarderai= s > sous Linux. This was supposed to be in English, I realized that one minute later... Received: from racine.noos.net ([212.198.2.71] helo=smtp.noos.fr) by usw-sf-list1.sourceforge.net with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id 17RwPE-0001RY-00 for <[EMAIL PROTECTED]>; Tue, 09 Jul 2002 07:55:56 -0700 Received: (qmail 23721640 invoked by uid 0); 9 Jul 2002 14:55:45 -0000 Received: from unknown (HELO mailivs.ivs.fr) ([212.198.228.212]) (envelope-sender <[EMAIL PROTECTED]>) by 212.198.2.71 (qmail-ldap-1.03) with SMTP for <[EMAIL PROTECTED]>; 9 Jul 2002 14:55:45 -0000 Received: from harry (unknown [192.168.0.146]) by mailivs.ivs.fr (Postfix) with SMTP id CC31923DC49 for <[EMAIL PROTECTED]>; Tue, 9 Jul 2002 16:54:20 +0200 (CEST) Message-ID: <[EMAIL PROTECTED]> From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Subject: Re: [NGL-devel] Re: [ngl-cvs] Changelog:... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 9 07:56:13 2002 X-Original-Date: Tue, 9 Jul 2002 16:55:40 +0200 I made the test on my laptop under WinXP. The results are quite astonishing: Win32 Debug with Inlining: int: Total: 21,040512 sec float: Total: 20,651021 sec Win32 Release with Inlining: int: Total: 9,580335 sec float Total: 9,935469 sec Win32 Release without Inlining: int: Total: 3,982881 sec float Total: 3,911000 sec I must say I'm quite surprised with the result. Vincent: do you confirm these on linux? It should (again) serve as an exemple of bad pratice of premature optimisation without testing :). Sebastien ----- Original Message ----- From: "Vincent Caron" <[EMAIL PROTECTED]> To: "NGL devel ML" <[EMAIL PROTECTED]> Sent: Tuesday, July 09, 2002 12:51 PM Subject: Re: [NGL-devel] Re: [ngl-cvs] Changelog:... On Tue, 2002-07-09 at 10:40, Sebastien Metrot wrote: > > > - moved nuiValue specialisations implementation to nuiProperty.cpp > > Ya une raison que je l'ai laissé dans le .h : ces fonctions sont censées > etre inline... On pourais en discuter avec de faire de genre de changement > qd meme... Ah, sorry. Ma politique est d'éviter le code dans les .h qd c'est possible (cad hors template). Et là je vois pas comment on peut gagner en perfs en inlinant ce code : - le SetValue() est pénalisé par l'appel a Changed() - le GetValue() est pénalisé par le nglString::Format() Tiens, je t'ai écrit un bench, comme ça on sera fixé. Je regarderais sous Linux. Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17S1k5-0007Uu-00 for <[EMAIL PROTECTED]>; Tue, 09 Jul 2002 13:37:50 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 7E4EDB4C1 for <[EMAIL PROTECTED]>; Tue, 9 Jul 2002 22:37:48 +0200 (CEST) Subject: Re: [NGL-devel] The mysteries of optimisation From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 9 13:38:16 2002 X-Original-Date: 09 Jul 2002 22:37:38 +0200 On Tue, 2002-07-09 at 16:55, Sebastien Metrot wrote: > I made the test on my laptop under WinXP. The results are quite astonishing: Linux results inserted below (P3-800). > Win32 Debug with Inlining: > int: Total: 21,040512 sec > float: Total: 20,651021 sec int: Total: 4.665817 sec float: Total: 7.887910 sec > Win32 Release with Inlining: > int: Total: 9,580335 sec > float Total: 9,935469 sec int: Total: 3.940325 sec float: Total: 7.542738 sec > Win32 Release without Inlining: > int: Total: 3,982881 sec > float Total: 3,911000 sec int: Total: 1.097463 sec float: Total: 1.198166 sec Pretty weird. We might be actually biased by our L2 cache, sometimes the hardware is better than the software :) Received: from meeloo.net ([62.4.18.112]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17S1om-0007ry-00 for <[EMAIL PROTECTED]>; Tue, 09 Jul 2002 13:42:41 -0700 Received: from harry ([10.1.1.4]) by meeloo.net with smtp (Exim 3.35 #1 (Debian)) id 17S1NH-0004Wo-00 for <[EMAIL PROTECTED]>; Tue, 09 Jul 2002 22:14:15 +0200 Message-ID: <[EMAIL PROTECTED]> From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]><[EMAIL PROTECTED]><[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Subject: Re: [NGL-devel] The mysteries of optimisation MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 9 13:43:14 2002 X-Original-Date: Tue, 9 Jul 2002 22:40:55 +0200 I'll test it on my Desktop computer just to be sure (bi P3 933 under win32). MeeLoo ----- Original Message ----- From: "Vincent Caron" <[EMAIL PROTECTED]> To: "NGL devel ML" <[EMAIL PROTECTED]> Sent: Tuesday, July 09, 2002 10:37 PM Subject: Re: [NGL-devel] The mysteries of optimisation > On Tue, 2002-07-09 at 16:55, Sebastien Metrot wrote: > > I made the test on my laptop under WinXP. The results are quite astonishing: > > Linux results inserted below (P3-800). > > > > Win32 Debug with Inlining: > > int: Total: 21,040512 sec > > float: Total: 20,651021 sec > > int: Total: 4.665817 sec > float: Total: 7.887910 sec > > > Win32 Release with Inlining: > > int: Total: 9,580335 sec > > float Total: 9,935469 sec > > int: Total: 3.940325 sec > float: Total: 7.542738 sec > > > Win32 Release without Inlining: > > int: Total: 3,982881 sec > > float Total: 3,911000 sec > > int: Total: 1.097463 sec > float: Total: 1.198166 sec > > Pretty weird. We might be actually biased by our L2 cache, sometimes the > hardware is better than the software :) > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Stuff, things, and much much more. > http://thinkgeek.com/sf > _______________________________________________ > NGL-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/ngl-devel > Received: from meeloo.net ([62.4.18.112]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17SZG4-0000zj-00; Thu, 11 Jul 2002 01:25:04 -0700 Received: from harry ([10.1.1.4]) by meeloo.net with smtp (Exim 3.35 #1 (Debian)) id 17SYok-0001f8-00; Thu, 11 Jul 2002 09:56:50 +0200 Message-ID: <[EMAIL PROTECTED]> From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>, <ngl-cvs@gna.org> References: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [NGL-devel] Re: [ngl-cvs] NoGFX target and the console... Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Thu Jul 11 01:26:03 2002 X-Original-Date: Thu, 11 Jul 2002 10:24:48 +0200 The solution is trivial: change the entry point of the nogfx targets to main instead of winmain so that we have a real console attached from the start and so we can do Ctrl+C from the console. I'll patch it as soon as I have time to do it. Sebastien ----- Original Message ----- From: "Vincent Caron" <[EMAIL PROTECTED]> To: <ngl-cvs@gna.org> Sent: Thursday, July 11, 2002 6:57 AM Subject: [ngl-cvs] NoGFX target and the console... > CVS reportCommit from zerodeux 2002/07/10 21:57:06 > > -------------------------------------------------------------------------- ------ > > NoGFX target and the console > > I recently made a modification on nglBaseApp::Quit()/win32, > comments/flames welcome. > > Quit() does not call PostQuitMessage() in NoGFX mode. > This is for the console demos (helloworld, conv, stream), they end with > Quit() and discard the nglConsole under win32. The right thing would be > to stop processing events for the user, ie. shutting down NGL but without > quitting the application. I don't know how it can be done. Imagine a > NoGFX app which uses network : it should stop receiving any event when > it calls Quit(), but not end the process to keep the window console open. > > I know you can run it through the debugger and voilà, but if you want > to distribute a release app (your game server ?), you're stuck. I don't > pretend it's a necessary feature. > > This is also maybe a good reason why we should have a closer look at > the win32 default console, playing a little more unix-ish (in this case > the console does not necessarily belongs to the NGL process). > > I had to replace the Quit() calls by PostQuitMessage() in the kbd accels > of nglConsole, since this is the only way to quit a NoGFX app currently :-/ > > 1 file modified > Module File name Version > ngl src/core/win32/nglConsole.cpp 1.7 >>> 1.8 > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > PC Mods, Computing goodies, cases & more > http://thinkgeek.com/sf > > > Received: from lafontaine.noos.net ([212.198.2.72] helo=smtp.noos.fr) by usw-sf-list1.sourceforge.net with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id 17Sghd-00074L-00 for <[EMAIL PROTECTED]>; Thu, 11 Jul 2002 09:22:01 -0700 Received: (qmail 14367554 invoked by uid 0); 11 Jul 2002 16:21:49 -0000 Received: from unknown (HELO mailivs.ivs.fr) ([212.198.228.212]) (envelope-sender <[EMAIL PROTECTED]>) by 212.198.2.72 (qmail-ldap-1.03) with SMTP for <ngl-cvs@gna.org>; 11 Jul 2002 16:21:49 -0000 Received: from harry (unknown [192.168.0.146]) by mailivs.ivs.fr (Postfix) with SMTP id CF80323DC49; Thu, 11 Jul 2002 18:20:29 +0200 (CEST) Message-ID: <[EMAIL PROTECTED]> From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>, <ngl-cvs@gna.org> References: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [NGL-devel] Re: [ngl-cvs] Improved win32 keyboard shortcuts (nglConsole and nglWindow)... Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Thu Jul 11 09:23:03 2002 X-Original-Date: Thu, 11 Jul 2002 18:21:44 +0200 There is a limit on 30Kb of console log under win32 that was introduced in one of these fixes... Someone will have to fix this (Vincent: you or me?). Seb ----- Original Message ----- From: "Vincent Caron" <[EMAIL PROTECTED]> To: <ngl-cvs@gna.org> Sent: Thursday, July 11, 2002 6:37 AM Subject: [ngl-cvs] Improved win32 keyboard shortcuts (nglConsole and nglWindow)... > CVS reportCommit from zerodeux 2002/07/10 21:37:13 > > -------------------------------------------------------------------------- ------ > > Improved win32 keyboard shortcuts (nglConsole and nglWindow) > > The nglConsole nows accept these shortcuts without setting the focus > specifically on the input entry : > > - Ctrl+Q or Ctrl+Break: quit now > - Ctrl+Sqr: hide console > 'Sqr' is the key below Esc, the one you never use except to bring > the Quake console :) > > Also implemented in nglWindow (and shown as a system menu item) : > > - Ctrl+Sqr: show console > > I also corrected the input proc override, my mess. I was so happy to get > it right that I also overrode the output proc, now I can really leave my > mouse alone. Next step: emulate VI and Emacs. > > BTW, is Ctrl+Q ok to quit the application ? My left hand fits nicely the > Ctrl+Q and Ctrl+Sqr shortcuts. Should be even better on a Qwerty :) > > At last, I also removed the mpBackLog code. > > 5 files modified > Module File name Version > ngl ChangeLog 1.48 >>> 1.49 > ngl examples/gears/GearWin.cpp 1.3 >>> 1.4 > ngl include/nglConsole.h 1.8 >>> 1.9 > ngl src/core/win32/nglConsole.cpp 1.6 >>> 1.7 > ngl src/core/win32/nglWindow.cpp 1.18 >>> 1.19 > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > PC Mods, Computing goodies, cases & more > http://thinkgeek.com/sf > > > Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17U7yX-0007dA-00 for <[EMAIL PROTECTED]>; Mon, 15 Jul 2002 08:41:25 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 41421B4C0 for <[EMAIL PROTECTED]>; Mon, 15 Jul 2002 17:41:23 +0200 (CEST) Subject: RE: [NGL-devel] Re: [ngl-cvs] started adding the code from Lorenzo Pastrana for a standard win32 console in ngl. From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Mon Jul 15 08:42:05 2002 X-Original-Date: 15 Jul 2002 17:41:17 +0200 On Tue, 2002-07-09 at 02:50, Lorenzo Pastrana wrote: > Was thinking about a pure abstract class to formalise app/console relation > and a looser dependence on implementation, since I had hard time thinking > about how to customzie the loop to be able to poll user input from standard > console, and still being complient with the overall design (Pop in/out > mechanism)... overloading nglConsole doesn't allow to do sutch a thing. The > level of abstraction / implementation is good for customizing console's > behaviour but not for the console's UI (unless mHistoryPosition, mHistory, > and the Completion method were protected (not private) members but still > doesn't solve mutch, see below). nglConsole is this kind of abstract class, even if it implements a 'default system console'. I agree this could be much better, and it will surely move to a real abstract class soon (NUI already overloads nglConsole's OnInput and OnOutput methods to provide a graphical console). > > > - if you want to do threading, do it right : there is an obvious race > > > condition where ThreadProc can access a console instance that can be > > > already destroyed in the main thread. Remember that nglConsole is a > > > singleton and that the user can destroy/replace it at any moment (this > > I guess the MAIN problem is here... > > /* public !! */ nglConsole::nglConsole(bool IsVisible) > { > // This is a singleton ??? (with a public constructor and no ::Instance() > method?) Not a perfectly academic singleton with its expected naming conventions, but you don't have a chance to build more that one nglConsole instance. > if (App.mpCon) > delete App.mpCon; // Here comes the race situation Among other things, the main problem being the console callbacks called in the console's thread, breaking the user event model (no reentrance in user callbacks). > I guess this is a real "NO-NO-YOU WON'T GET THAT FUNKY CUSTOM CONSOLE" or > I'm missing something(feature?)...??? > may be better a factory method provided by the subclass (optionnal)... ?? You *can* have a funky console, try 'nui/examples/nuitest'. It's minimal. > (WCHAR NEWBIE) > maybe you can point me to some docs? > what is the general ngl policy/method for unicode? Okay, this is a boring issue. First have a look at nglString documentation. Then you have to support two modes when it comes to sending some strings to OS methods : #ifdef USE_WCHAR // nglChar is actually a wchar_t wprintf("%s", theString.GetChars()); #else // nglChar is a 'char', and the encoding is the locale's one printf("%s", theString.GetChars()); #endif Many win32 methods have their widechar counterpart. If there's not, you have to use nglStringConv to do the proper conversions (look at nglConsole's code). Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17U9zX-0005ZS-00 for <[EMAIL PROTECTED]>; Mon, 15 Jul 2002 10:50:35 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 73DA0B4C0 for <[EMAIL PROTECTED]>; Mon, 15 Jul 2002 19:50:35 +0200 (CEST) From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Subject: [NGL-devel] Note on STL usage Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Mon Jul 15 10:51:04 2002 X-Original-Date: 15 Jul 2002 19:50:28 +0200 We just switched STL usage from 'no namespace' to std:: namespace (seems to be the standard). We'll keep the habit of prefixing STL types with std:: from now. Feedback from namespace users is welcome (eh Lorenzo ? :)) Received: from logic.phpwebhosting.com ([66.33.1.213]) by usw-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17UEkV-0004q3-00 for <[EMAIL PROTECTED]>; Mon, 15 Jul 2002 15:55:23 -0700 Received: (qmail 13851 invoked by uid 508); 15 Jul 2002 22:55:11 -0000 Received: from unknown (HELO wraith) (212.195.189.93) by logic.phpwebhosting.com with SMTP; 15 Jul 2002 22:55:11 -0000 From: "Lorenzo Pastrana" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: RE: [NGL-devel] Note on STL usage Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <[EMAIL PROTECTED]> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Mon Jul 15 15:56:02 2002 X-Original-Date: Tue, 16 Jul 2002 00:53:00 +0200 Mbeh! looks like it builds and runs like a charm ;D So i can't say mutch more for the moment; but of course I'll be snapping reports whenever something goes wrong.. Lo. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Vincent Caron > Sent: lundi 15 juillet 2002 19:50 > To: NGL devel ML > Subject: [NGL-devel] Note on STL usage > > > We just switched STL usage from 'no namespace' to std:: namespace (seems > to be the standard). We'll keep the habit of prefixing STL types with > std:: from now. Feedback from namespace users is welcome (eh Lorenzo ? > :)) > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > NGL-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/ngl-devel > Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17UWBd-0000mV-00 for <[EMAIL PROTECTED]>; Tue, 16 Jul 2002 10:32:34 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 17D19B3D0 for <[EMAIL PROTECTED]>; Tue, 16 Jul 2002 19:32:32 +0200 (CEST) From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Subject: [NGL-devel] Cleanup proposal (NGL application stuff) Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 16 10:33:13 2002 X-Original-Date: 16 Jul 2002 19:32:24 +0200 Some thoughts I had this night while trying to sleep (the sun has that bad habit of waking up when I go to bed). I wrote then down, it's on a paper right in front of me and still looks coherent to me after I had my coffee (it's only 7PM here after all). A) This renaming : - nglBaseApp -> nglApplicationBase - nglApp -> nglApplication The first because the 'Base' SUFfix has become a 'de facto' standard in NGL/NUI, and I tend to like it. Makes nglApplication and nglApplicationBase side by side in the doc. Still valid english when you read it. Etc. The latter because it turns out you only use two occurences of this word in your application : the '#include' and the ': public nglApp'. Or maybe not at all if you use the portable NGL_APP_TYPE (most NGL examples). While it's a good idea to have a short instance name (App), there's no point at being so spare on a so unique class. And it's compatible with the obvious choice of nglQuat in place of nglQuaternion, 'cause if you use quaternions you'll need a bunch of them. B) Document the user application instance. The only exported symbol (via an 'extern' declaration in nglApp.h or nglBaseApp.h) is 'App', actually a reference to the real 'UserApp' instance of UserApplication type, but casted to NGL_APP_TYPE. It's needed in many places of NGL, and most users won't realize that OUT() and LOG() actually access the application's console and log respectively via this reference. We can't provide the 'extern UserApplication UserApp' declaration in NGL since we don't have the UserApplication class ! This is still the user's job. However this would be sufficient IMHO : - change 'UserApp' static instance name to a nicer 'MyApp' (ie. adopt the user's point of view, not NGL's one) - document this 'MyApp' symbol, encouraging a perfectly legal 'extern class MyAppType MyApp;' C) Provide the framework for DLL target. We are actually a few lines from this. I already moved the init code a few months before, and both main() and WinMain() are one-liners. We would have to : - improve the nglDeclareApp() macro to support a DLL target. Currently trivial for Unix and Windows. * We need a macro to choose the link method, what about USE_DLL ? This would require a -DNO_DLL for static linkage, and the closer I get to packaging and SDK distribution pb, the more I'd like DLL as a default. Of course this would stay 'static' at first, just like USE_WCHAR is not currently the default, until it matures. * This could also be two different declaration macros, but this would prevent automatic compilation as both static and DLL targets without modyfing the code. Bad idea IHMO. - move the WinMain() and main() implementation for the static target in their own file, hence : * the static and DLL targets only differ by a file (different dsp for win32 I guess) * no USE_DLL in NGL code * share exactly the same object files (static target has one more), only linkage differs D) Optional : bring in a nuiApplication class. Would be currently a stub (': public nglApplication'), but is expected to be useful in a near future. Also provide a stubby nuiDeclareApp to make application design look definitively cool :). All these changes are actually very small patches and non-invasive. This even doesn't break the ABI for the static target ('App' is preserved). I'd like to apply them quickly, share your opinons. Received: from logic.phpwebhosting.com ([66.33.1.213]) by usw-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17Uca2-0007FG-00 for <[EMAIL PROTECTED]>; Tue, 16 Jul 2002 17:22:10 -0700 Received: (qmail 13161 invoked by uid 508); 17 Jul 2002 00:21:59 -0000 Received: from unknown (HELO wraith) (212.194.67.100) by logic.phpwebhosting.com with SMTP; 17 Jul 2002 00:21:59 -0000 From: "Lorenzo Pastrana" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: RE: [NGL-devel] Cleanup proposal (NGL application stuff) Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <[EMAIL PROTECTED]> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 16 17:23:06 2002 X-Original-Date: Wed, 17 Jul 2002 02:19:47 +0200 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Vincent Caron > Sent: mardi 16 juillet 2002 19:32 > To: NGL devel ML > Subject: [NGL-devel] Cleanup proposal (NGL application stuff) > > > Some thoughts I had this night while trying to sleep (the sun has that > bad habit of waking up when I go to bed). I wrote then down, it's on a > paper right in front of me and still looks coherent to me after I had my > coffee (it's only 7PM here after all). > > > A) This renaming : > > - nglBaseApp -> nglApplicationBase > - nglApp -> nglApplication > > The first because the 'Base' SUFfix has become a 'de facto' standard in > NGL/NUI, and I tend to like it. Makes nglApplication and > nglApplicationBase side by side in the doc. Still valid english when you > read it. Etc. > > The latter because it turns out you only use two occurences of this > word in your application : the '#include' and the ': public nglApp'. Or > maybe not at all if you use the portable NGL_APP_TYPE (most NGL > examples). > > While it's a good idea to have a short instance name (App), there's no > point at being so spare on a so unique class. And it's compatible with > the obvious choice of nglQuat in place of nglQuaternion, 'cause if you > use quaternions you'll need a bunch of them. > Well sounds ok, not critical though.. :) > > B) Document the user application instance. > > The only exported symbol (via an 'extern' declaration in nglApp.h or > nglBaseApp.h) is 'App', actually a reference to the real 'UserApp' > instance of UserApplication type, but casted to NGL_APP_TYPE. It's > needed in many places of NGL, and most users won't realize that OUT() > and LOG() actually access the application's console and log respectively > via this reference. > > We can't provide the 'extern UserApplication UserApp' declaration in > NGL since we don't have the UserApplication class ! This is still the > user's job. However this would be sufficient IMHO : > > - change 'UserApp' static instance name to a nicer 'MyApp' (ie. adopt > the user's point of view, not NGL's one) > I agree with this one on the 'user's point of view' argument.. > - document this 'MyApp' symbol, encouraging a perfectly legal 'extern > class MyAppType MyApp;' > > > C) Provide the framework for DLL target. > > We are actually a few lines from this. I already moved the init code a > few months before, and both main() and WinMain() are one-liners. We > would have to : > > - improve the nglDeclareApp() macro to support a DLL target. Currently > trivial for Unix and Windows. > > * We need a macro to choose the link method, what about USE_DLL ? > This would require a -DNO_DLL for static linkage, and the closer I get > to packaging and SDK distribution pb, the more I'd like DLL as a > default. Of course this would stay 'static' at first, just like > USE_WCHAR is not currently the default, until it matures. > > * This could also be two different declaration macros, but this would > prevent automatic compilation as both static and DLL targets without > modyfing the code. Bad idea IHMO. > Here is some 'standard' way of MACROING the target selection on win32. #ifdef NGL_EXPORTS # define NGL_API __declspec(dllexport) #else # ifdef NGL_IMPORT # define NGL_API __declspec(dllimport) # else # define NGL_API # endif #endif BUT, the snazzy point is that EVERY single class(and all parent/member class!!) and functions you'd like to export from a dll would have to be prefixed by an appropriate declaration to be ok : class SomeFutureMember; class NGL_API ParentClass; class NGL_API MyAppOrWhatever // Ok. : public ParentClass // Ok. { SomeFutureMember mSfm; // RRRHHUUU ! try again ? etc.. }; void NGL_API DoSomethingCool(); I've just gone thru this pretty painfull process and finally got used to stick MY_API everywhere (this is particularly crude on template classes / stl-stuff witch needs to be typedef'ed to compile.. VC6 still eroneousliy reports 'non dll interface' on those ones so you have to check it all by hand...) Don't know exactly how dynamic linking works on linux et al. but it is possible to define the NGL_API macro on each plateform... even if it has to stay a NULL macro. > - move the WinMain() and main() implementation for the static target in > their own file, hence : > > * the static and DLL targets only differ by a file (different dsp for > win32 I guess) > * no USE_DLL in NGL code > * share exactly the same object files (static target has one more), > only linkage differs > > > D) Optional : bring in a nuiApplication class. > > Would be currently a stub (': public nglApplication'), but is expected > to be useful in a near future. Also provide a stubby nuiDeclareApp to > make application design look definitively cool :). > Sounds 'obvious'.. !? =D > > All these changes are actually very small patches and non-invasive. This > even doesn't break the ABI for the static target ('App' is preserved). > I'd like to apply them quickly, share your opinons. almost all, but none would affect client code.. > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > NGL-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/ngl-devel > Received: from meeloo.net ([62.4.18.112]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17Ug1W-0003Pf-00 for <[EMAIL PROTECTED]>; Tue, 16 Jul 2002 21:02:47 -0700 Received: from harry ([10.1.1.4]) by meeloo.net with smtp (Exim 3.35 #1 (Debian)) id 17UfaF-0002wY-00 for <[EMAIL PROTECTED]>; Wed, 17 Jul 2002 05:34:35 +0200 Message-ID: <[EMAIL PROTECTED]> From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Subject: Re: [NGL-devel] Cleanup proposal (NGL application stuff) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 16 21:03:02 2002 X-Original-Date: Wed, 17 Jul 2002 06:01:47 +0200 ----- Original Message ----- From: "Lorenzo Pastrana" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 17, 2002 2:19 AM Subject: RE: [NGL-devel] Cleanup proposal (NGL application stuff) > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Vincent Caron > > Sent: mardi 16 juillet 2002 19:32 > > To: NGL devel ML > > Subject: [NGL-devel] Cleanup proposal (NGL application stuff) > > > > C) Provide the framework for DLL target. > > I don't see any benefit in this, particularly speaking of win32. - There is no standard way to do dll versioning under win32 (no other than to change the dll name at each new version which kills the whole concept). - Dlls are confusing users. - Dlls are confusing developpers and makes for totaly unbearable installation process. (just see how painfull it is to manage the MFC dlls versions for a MFC app, there's no way I want this for ngl...). - Templates over dll just plain don't work right (just ask the libsigc people). - A dll for ngl will not make us gain vast amounts of RAM for the code as the chances for multiple programs to uses ngl at the same time are really small. - How would manage all the different possible NGL target in a single dll? (with all the options: image codec inclusion, main loop support, maya support, unicode/mbcs, etc...?). If you can't manage to have all options in ONE dll we will have to cope with multiple versions at once which, once again, just kills the whole benefits of factorizing code in a dll. And i'm not even talking about the pain it will be to support all the suplemental (and stupid) glue code to be able to export C++ symbols (exporting C function is easy, C++ is just a nightmare). > > * We need a macro to choose the link method, what about USE_DLL ? > > This would require a -DNO_DLL for static linkage, and the closer I get > > to packaging and SDK distribution pb, the more I'd like DLL as a > > default. Of course this would stay 'static' at first, just like > > USE_WCHAR is not currently the default, until it matures. > > That's only working for unices. Win32 still need explicit project description files. I'm planning to create as many ngl projects (dsps) as there are targets (app, maya plugin, no gfx app, etc...). > > * This could also be two different declaration macros, but this would > > prevent automatic compilation as both static and DLL targets without > > modyfing the code. Bad idea IHMO. > > ??? > > Here is some 'standard' way of MACROING the target selection on win32. > > #ifdef NGL_EXPORTS > # define NGL_API __declspec(dllexport) > #else > # ifdef NGL_IMPORT > # define NGL_API __declspec(dllimport) > # else > # define NGL_API > # endif > #endif > > BUT, the snazzy point is that EVERY single class(and all parent/member > class!!) and functions you'd like to export from a dll would have to be > prefixed by an appropriate declaration to be ok : > > class SomeFutureMember; > class NGL_API ParentClass; > > class NGL_API MyAppOrWhatever // Ok. > : public ParentClass // Ok. > { > SomeFutureMember mSfm; // RRRHHUUU ! try again ? > etc.. > }; > > void NGL_API DoSomethingCool(); > > I've just gone thru this pretty painfull process and finally got used to > stick MY_API everywhere (this is particularly crude on template classes / > stl-stuff witch needs to be typedef'ed to compile.. VC6 still eroneousliy > reports 'non dll interface' on those ones so you have to check it all by > hand...) > > Don't know exactly how dynamic linking works on linux et al. but it is > possible to define the NGL_API macro on each plateform... even if it has to > stay a NULL macro. > This is just a nightmare. There's just not enough benefit to make the effort worth. I vote 200% AGAINST a dll version of NGL. NGL was meant to be static from the begining, we are not going to succeed turning it into a dll like that, like two weeks before the first release. > > - move the WinMain() and main() implementation for the static target in > > their own file, hence : > > > > * the static and DLL targets only differ by a file (different dsp for > > win32 I guess) > > * no USE_DLL in NGL code > > * share exactly the same object files (static target has one more), > > only linkage differs > > If it was the only change necessary i'd be OK but as Lorenzo pointed out we will have to prefix each and every classes & function in the code which will have to be enforced by Win32 for every plateform supported. And that's not worth it in my not humble opinion (under win32 anyway, if the target is easy for unices then I don't have problems if YOU support it :-)). MeeLoo Received: from logic.phpwebhosting.com ([66.33.1.213]) by usw-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17Ure5-0001fr-00 for <[EMAIL PROTECTED]>; Wed, 17 Jul 2002 09:27:21 -0700 Received: (qmail 2079 invoked by uid 508); 17 Jul 2002 16:27:10 -0000 Received: from unknown (HELO wraith) (212.195.85.128) by logic.phpwebhosting.com with SMTP; 17 Jul 2002 16:27:10 -0000 From: "Lorenzo Pastrana" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: RE: [NGL-devel] Cleanup proposal (NGL application stuff) Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <[EMAIL PROTECTED]> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Wed Jul 17 09:28:03 2002 X-Original-Date: Wed, 17 Jul 2002 18:24:58 +0200 Maybe, before discussing the 'ways' and 'pains' of making a DLL version of NGL it could be usefull to clear the fog around the reasons of sutch a version? The simple reason I can see by now comes from my bet on NGL' success ... - This would probably save some bandwith to have a shared NGL object for multiple applications using it... - May be allowing some automated upgrade mechanism... This could be done quietly after the release ... taking the time to plan and design everithing correctly ... BTW nothing in the hell will make you do the same shitty mistakes as MS (when there's no standard or the actual is crappy, make your own...) Lo. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Sebastien > Metrot > Sent: mercredi 17 juillet 2002 06:02 > To: [EMAIL PROTECTED] > Subject: Re: [NGL-devel] Cleanup proposal (NGL application stuff) > > > > ----- Original Message ----- > From: "Lorenzo Pastrana" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, July 17, 2002 2:19 AM > Subject: RE: [NGL-devel] Cleanup proposal (NGL application stuff) > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf Of > Vincent Caron > > > Sent: mardi 16 juillet 2002 19:32 > > > To: NGL devel ML > > > Subject: [NGL-devel] Cleanup proposal (NGL application stuff) > > > > > > C) Provide the framework for DLL target. > > > > > I don't see any benefit in this, particularly speaking of win32. > - There is no standard way to do dll versioning under win32 (no other than > to change the dll name at each new version which kills the whole concept). > - Dlls are confusing users. > - Dlls are confusing developpers and makes for totaly unbearable > installation process. (just see how painfull it is to manage the MFC dlls > versions for a MFC app, there's no way I want this for ngl...). > - Templates over dll just plain don't work right (just ask the libsigc > people). > - A dll for ngl will not make us gain vast amounts of RAM for the code as > the chances for multiple programs to uses ngl at the same time are really > small. > - How would manage all the different possible NGL target in a single dll? > (with all the options: image codec inclusion, main loop support, maya > support, unicode/mbcs, etc...?). If you can't manage to have all > options in > ONE dll we will have to cope with multiple versions at once which, once > again, just kills the whole benefits of factorizing code in a dll. > > And i'm not even talking about the pain it will be to support all the > suplemental (and stupid) glue code to be able to export C++ symbols > (exporting C function is easy, C++ is just a nightmare). > > > > > * We need a macro to choose the link method, what about USE_DLL ? > > > This would require a -DNO_DLL for static linkage, and the closer I get > > > to packaging and SDK distribution pb, the more I'd like DLL as a > > > default. Of course this would stay 'static' at first, just like > > > USE_WCHAR is not currently the default, until it matures. > > > > > That's only working for unices. Win32 still need explicit project > description files. I'm planning to create as many ngl projects (dsps) as > there are targets (app, maya plugin, no gfx app, etc...). > > > > * This could also be two different declaration macros, but > this would > > > prevent automatic compilation as both static and DLL targets without > > > modyfing the code. Bad idea IHMO. > > > > > ??? > > > > > Here is some 'standard' way of MACROING the target selection on win32. > > > > #ifdef NGL_EXPORTS > > # define NGL_API __declspec(dllexport) > > #else > > # ifdef NGL_IMPORT > > # define NGL_API __declspec(dllimport) > > # else > > # define NGL_API > > # endif > > #endif > > > > BUT, the snazzy point is that EVERY single class(and all parent/member > > class!!) and functions you'd like to export from a dll would have to be > > prefixed by an appropriate declaration to be ok : > > > > class SomeFutureMember; > > class NGL_API ParentClass; > > > > class NGL_API MyAppOrWhatever // Ok. > > : public ParentClass // Ok. > > { > > SomeFutureMember mSfm; // RRRHHUUU ! try again ? > > etc.. > > }; > > > > void NGL_API DoSomethingCool(); > > > > I've just gone thru this pretty painfull process and finally got used to > > stick MY_API everywhere (this is particularly crude on template > classes / > > stl-stuff witch needs to be typedef'ed to compile.. VC6 still > eroneousliy > > reports 'non dll interface' on those ones so you have to check it all by > > hand...) > > > > Don't know exactly how dynamic linking works on linux et al. but it is > > possible to define the NGL_API macro on each plateform... even if it has > to > > stay a NULL macro. > > > > > This is just a nightmare. There's just not enough benefit to make > the effort > worth. I vote 200% AGAINST a dll version of NGL. > > NGL was meant to be static from the begining, we are not going to succeed > turning it into a dll like that, like two weeks before the first release. > > > > - move the WinMain() and main() implementation for the > static target in > > > their own file, hence : > > > > > > * the static and DLL targets only differ by a file > (different dsp for > > > win32 I guess) > > > * no USE_DLL in NGL code > > > * share exactly the same object files (static target has one more), > > > only linkage differs > > > > > If it was the only change necessary i'd be OK but as Lorenzo > pointed out we > will have to prefix each and every classes & function in the code > which will > have to be enforced by Win32 for every plateform supported. And that's not > worth it in my not humble opinion (under win32 anyway, if the > target is easy > for unices then I don't have problems if YOU support it :-)). > > > MeeLoo > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > NGL-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/ngl-devel > Received: from verlaine.noos.net ([212.198.2.73] helo=smtp.noos.fr) by usw-sf-list1.sourceforge.net with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id 17Usqn-0000CL-00 for <[EMAIL PROTECTED]>; Wed, 17 Jul 2002 10:44:33 -0700 Received: (qmail 33382131 invoked by uid 0); 17 Jul 2002 17:44:22 -0000 Received: from unknown (HELO mailivs.ivs.fr) ([212.198.228.212]) (envelope-sender <[EMAIL PROTECTED]>) by 212.198.2.73 (qmail-ldap-1.03) with SMTP for <[EMAIL PROTECTED]>; 17 Jul 2002 17:44:22 -0000 Received: from harry (unknown [192.168.0.146]) by mailivs.ivs.fr (Postfix) with SMTP id 5A6C023DC49 for <[EMAIL PROTECTED]>; Wed, 17 Jul 2002 19:41:26 +0200 (CEST) Message-ID: <[EMAIL PROTECTED]> From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Subject: Re: [NGL-devel] Cleanup proposal (NGL application stuff) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Wed Jul 17 10:45:08 2002 X-Original-Date: Wed, 17 Jul 2002 19:43:51 +0200 ----- Original Message ----- From: "Lorenzo Pastrana" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 17, 2002 6:24 PM Subject: RE: [NGL-devel] Cleanup proposal (NGL application stuff) > > Maybe, before discussing the 'ways' and 'pains' of making a DLL version of > NGL it could be usefull to clear the fog around the reasons of sutch a > version? Sure :) > > The simple reason I can see by now comes from my bet on NGL' success ... > - This would probably save some bandwith to have a shared NGL object for > multiple applications using it... As I explained before this argument just doesn't work right if you look at it seriously (i'm talking about windows and mac platform, i.e. platforms that do not have a good packaging system) - DLLs are confusing users. I do not count the times when I wanted to try some new opengl demo on opengl.org (for example) and the zip contained only the exe and not the dlls it needed (glut, libsdl, etc...). I had to get the dll pack by hand (many times it was on some completely diferent server and i had to dig my way through pages of irrevelent infos to find it). Then i have to install them in c:\windows\system32 and some other stupid places that the user NEVER wants to hear about (even *I* don't want to hear about it...). Most of the time I grew tired and gave up even before I could watch the cool demo... Then you may say that you could provide the dlls in your package... and there goes the argument that DLLs permits to save bandwith or harddrive space... - DLLs are NOT a good way to manage upgrades, and in fact it may even complicate upgrades quite a lot. Here are the things that I learned at Cryo doing the upgrade system: * The main argument towards using DLLs is that you can factorize code used by multiple application. But if you have two applications using the same DLL you need to be sure that upgrading the DLL for one will not break the other one by adding/removing some bugs or features It relies on (I have seen that MANY times). Then the only way to make the upgrade less painfull is to add the version number to the DLL name or to provide a stub DLL (try to wrap you head around this one...). Yes but then, hey, we are not factorizing code anymore, we are plainly multiplying versions of the same DLLs in order to prevent breaking the current applications using them. And there goes our argument that DLLs help factorise code as most of the time having more than one application using a dll means having multiple versions of it. These arguments, I repeat myself, may not at all be true in a unix system with a good packaging system (debian ;) and the usual unix bag of tricks (links & all). I have another motivation against dlls under win32 & MacOS: I have regurlaly used Windows since many years and I really love the experience (well most of the time it's ok :)). And many people know what I feel about the Mac platform (recurent nervous system breakdown ;-)), but there is ONE thing i really love about the mac: NO DLLs!!! The mecanism exists of course but most people seems to be happy by shipping just a static executable and be done with it (except for system extensions). The user is also VERY HAPPY not to have to deal with them at all, which means being able to uninstall an application just by putting it's folder to the trash (and installation is as easy as draging a binary to the harddrive...). In the end I have a final motivation not to want to start using NGL as a DLL: DLLs under win32 & MacOS share the same data segment when they are in the same executable (is it the same under unix?). For example some probject I hope to be working on soon will involve building an executable with NGL and building plugins for this executable also with NGL. The only way I know to make a plugin system under the platform NGL supports right now is to make a DLL and load it in the host. If we use NGL in a DLL then each new plugin loading up will reinit the data segment and overwrite the nglApplication instance pointer and all others globally defined data which I'm pretty sure will break the whole system down. > - May be allowing some automated upgrade mechanism... > > This could be done quietly after the release ... taking the time to plan and > design everithing correctly ... BTW nothing in the hell will make you do the > same shitty mistakes as MS (when there's no standard or the actual is > crappy, make your own...) > I agree. First make the release work as well as possible with the current decided feature set, then fight over the next ones :). Anyway, I'm pretty sure many people with disagree with some or all of these arguments but well... I don't understand the sentence about MS & standards though... Can you elaborate a bit? ;) > Lo. > MeeLoo Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17UvqO-00018L-00 for <[EMAIL PROTECTED]>; Wed, 17 Jul 2002 13:56:20 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 6437BB42B for <[EMAIL PROTECTED]>; Wed, 17 Jul 2002 22:56:19 +0200 (CEST) Subject: Re: [NGL-devel] Cleanup proposal (NGL application stuff) From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Wed Jul 17 13:57:02 2002 X-Original-Date: 17 Jul 2002 22:56:08 +0200 On Wed, 2002-07-17 at 06:01, Sebastien Metrot wrote: > > C) Provide the framework for DLL target. > > I don't see any benefit in this, particularly speaking of win32. The 'speaking of win32' is important. You're talking about the 'DLL Hell'. I just searched the web for more info on this recurrent story. I found enough articles on MSDN to understand why they stress the uppercase 'H' in 'Hell'. It's not really our topic, but I suggest someone sends the (100 lines) Linux ld.so man page to Redmond, they really need to get a clue. Now speaking of Unix, DLL support is mandatory for packaging. And I'll support packaging (deb, rpm). It offers a number of features over the static lib that nobody wants to loose : <boring Unixer experience> - Orthogonality : the only way to track bugs efficiently is to isolate very module and do versionning. Nobody at Debian would like to force the release of all NGL dependent packages when the NGL package itself is updated for bugfixes reasons. Nor even try to understand which personal taste of NGL a developer statically linked into its app. Nobody will maintain such a thing. - Component-wise : distro and users keep the control, they can choose to replace components, user older ones, or whatever they need. The best example comes with binary-only software : VMWare 2.x was relying on a glibc bug. When that glibc bug got fixed, VMWare stopped working. I simply kept a copy of the buggy libc and ran VMWare against it with a simple LD_LIBRARY_PRELOAD. If the libc was statically compiled in VMWare, it would not have been possible for me to upgrade my kernel below a known version. And it would have forced the VMWare people to do all the libc bugtracking that RedHat, Mandrake, Suse and others do, merge all those patches, and make frequent releases of VMWare. Nobody wants to do that. - API stability and ABI guarantee. Since DLL releases imply binary compatibility (and not source compatibility as for a static lib), this ensure two thing for the developper : * ABI is preserved as long as the DLL major is unchanged (not related to NGL's major), and further ABI updates can live happily side-by-side * API is very stable, since ABI compatibility implies that the only API modifications are additions. </boring Unixer experience> Conclusion : least developer and user suffering occurs with DLL under the Unix distro scheme. Looks like the reverse of Win32. > - How would manage all the different possible NGL target in a single dll? > (with all the options: image codec inclusion, main loop support, maya > support, unicode/mbcs, etc...?). If you can't manage to have all options in > ONE dll we will have to cope with multiple versions at once which, once > again, just kills the whole benefits of factorizing code in a dll. This is a packaging issue. The rule is 'compile in all stable features'. In our case this makes dependencies on zlib, libpng, libjpeg and freetype. The USE_WCHAR is an issue, but Qt has the same kind of conditional compile. They made a choice : it was no_wchar for Qt2 (developer were not interested), it his wchar for Qt3 (developers begged for it !). Non-mainstream people (requiring stripped-down version, etc) still compile Qt statically and happily. For instance I'll obviously package libngl.deb with NOGFX turned off. Again, this DLL thing is a feature, and it does not have to be supported by win32. I just wish I could apt-get 'libngl' and 'libngl-devel' under win32... Before I port dpkg to win32, I will at least support proper packaging for Unix people :) Anyway, this will the subject of a next discussion : I need the Maya or Netscape plugins classes to be subclasses of nglApp. Looking carefully at nglApp and Maya plugin interface, it also occurs to me that it is rather a wise design. Forcing me to do the right and proper hooks into the event loop, etc. The #ifdef kludges in nglBaseApp should only deal with _NOGFX_, adding _MAYAPLUGIN_ in here makes the code pas beau du tout. > And i'm not even talking about the pain it will be to support all the > suplemental (and stupid) glue code to be able to export C++ symbols > (exporting C function is easy, C++ is just a nightmare). If it's just a matter of appending that little constant blurb in front of those symbols, I don't see the pb. Maintaining a .def file is clearly not funny. And I don't see a linker option to export all symbols as a default :(. > > > * We need a macro to choose the link method, what about USE_DLL ? > > That's only working for unices. Win32 still need explicit project > description files. I'm planning to create as many ngl projects (dsps) as > there are targets (app, maya plugin, no gfx app, etc...). OK, sounds heplful. Will just be not funny when we add a .cpp :) > > BUT, the snazzy point is that EVERY single class(and all parent/member > > class!!) and functions you'd like to export from a dll would have to be > > prefixed by an appropriate declaration to be ok : C++ is full of those little obligations that are obviously boring, but nontheless worth the effort when you intend to make your code sharable and portable. Ask Meeloo for the 'const and temporary instances pb' and my frequent NUI fixes ! :). The NGL_API doesn't scare me one second. > > I've just gone thru this pretty painfull process and finally got used to > > stick MY_API everywhere (this is particularly crude on template classes / > > stl-stuff witch needs to be typedef'ed to compile.. VC6 still eroneousliy > > reports 'non dll interface' on those ones so you have to check it all by > > hand...) Even if VC6 was smart enough to export templates automagically, you would quicky find a platform/compiler combo that would'nt do it. Of couse this is true in NGL context : satisfy compiler rants as long as it does not impact on code (interface, size or performance). Meeloo and I acquired code habits that don't break the build on both Linux and Win32 in most commits. I said _most_ ;) Of course, the NGL user has no such constraints, if he wants to do ATL over NGL, it's not my pb :) > > Don't know exactly how dynamic linking works on linux et al. but it is > > possible to define the NGL_API macro on each plateform... even if it has > > to stay a NULL macro. ld export all symbols for SO as a default. Then you got the same smala as win32 (compiler directive per symbol, export file, etc). > NGL was meant to be static from the begining, we are not going to succeed > turning it into a dll like that, like two weeks before the first release. I only need Unix DLL support, and it's a trivial patch we intend to do anyway. That is moving the application entry point into the user's own code. Last discussion with Meeloo gave this option : #ifdef _WIN32_ #define NGL_MAINPROC \ int __stdcall WinMain(...) { return App.WinMain(...); } #else #define NGL_MAINPROC \ int main(...) { return App.main(...); } #endif /* User will put this one in one of its header files */ #define NGL_DECLARE_APP(AppType) extern AppType UserApp; /* This one goes in one of the .cpp files */ #define NGL_IMPLEMENT_APP(AppType) \ AppType UserApp; \ NGL_APP_TYPE& App = UserApp; \ NGL_MAINPROC Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17V1ir-0003sf-00 for <[EMAIL PROTECTED]>; Wed, 17 Jul 2002 20:12:58 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id A6018AFB9 for <[EMAIL PROTECTED]>; Thu, 18 Jul 2002 05:12:59 +0200 (CEST) From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Subject: [NGL-devel] The online doc has been updated from CVS Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Wed Jul 17 20:13:02 2002 X-Original-Date: 18 Jul 2002 05:12:44 +0200 ... due to the recent name changes (both NGL & NUI manuals). http://ngl.sf.net/doc.php Received: from zola.noos.net ([212.198.2.76] helo=smtp.noos.fr) by usw-sf-list1.sourceforge.net with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id 17V9Cp-0003ux-00 for <[EMAIL PROTECTED]>; Thu, 18 Jul 2002 04:12:24 -0700 Received: (qmail 44468533 invoked by uid 0); 18 Jul 2002 11:12:13 -0000 Received: from unknown (HELO mailivs.ivs.fr) ([212.198.228.212]) (envelope-sender <[EMAIL PROTECTED]>) by 212.198.2.76 (qmail-ldap-1.03) with SMTP for <[EMAIL PROTECTED]>; 18 Jul 2002 11:12:13 -0000 Received: from harry (unknown [192.168.0.146]) by mailivs.ivs.fr (Postfix) with SMTP id 425EC23DC49 for <[EMAIL PROTECTED]>; Thu, 18 Jul 2002 13:09:19 +0200 (CEST) Message-ID: <[EMAIL PROTECTED]> From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [NGL-devel] Re: [ngl-cvs] Renaming session... Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Thu Jul 18 04:13:06 2002 X-Original-Date: Thu, 18 Jul 2002 13:11:39 +0200 ----- Original Message ----- From: "Vincent Caron" <[EMAIL PROTECTED]> To: <ngl-cvs@gna.org> Sent: Thursday, July 18, 2002 4:17 AM Subject: [ngl-cvs] Renaming session... > CVS reportCommit from zerodeux 2002/07/17 19:17:36 > > -------------------------------------------------------------------------- ------ > > Renaming session > - nglApp -> nglApplication > - nglBaseApp -> nglApplicationBase > - nglDeclareApp -> NGL_APP_CREATE > - new NGL_APP_DECLARE > In fact I don't much like NGL_APP_DECLARE, I would much prefer something like NGL_APP_USE (just like we are "using" namespaces...) or something like that (import?). This is not very important but we are usualy quite picky about choosing API names :). MeeLoo Received: from aragon.noos.net ([212.198.2.75] helo=smtp.noos.fr) by usw-sf-list1.sourceforge.net with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id 17V9qT-0001Ub-00 for <[EMAIL PROTECTED]>; Thu, 18 Jul 2002 04:53:21 -0700 Received: (qmail 8103750 invoked by uid 0); 18 Jul 2002 11:53:11 -0000 Received: from unknown (HELO mailivs.ivs.fr) ([212.198.228.212]) (envelope-sender <[EMAIL PROTECTED]>) by 212.198.2.75 (qmail-ldap-1.03) with SMTP for <[EMAIL PROTECTED]>; 18 Jul 2002 11:53:11 -0000 Received: from harry (unknown [192.168.0.146]) by mailivs.ivs.fr (Postfix) with SMTP id 1F14123DC49 for <[EMAIL PROTECTED]>; Thu, 18 Jul 2002 13:50:17 +0200 (CEST) Message-ID: <[EMAIL PROTECTED]> From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Subject: Re: [NGL-devel] Cleanup proposal (NGL application stuff) MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Thu Jul 18 04:54:03 2002 X-Original-Date: Thu, 18 Jul 2002 13:52:37 +0200 ----- Original Message ----- From: "Vincent Caron" <[EMAIL PROTECTED]> To: "NGL devel ML" <[EMAIL PROTECTED]> Sent: Wednesday, July 17, 2002 10:56 PM Subject: Re: [NGL-devel] Cleanup proposal (NGL application stuff) > On Wed, 2002-07-17 at 06:01, Sebastien Metrot wrote: > > > C) Provide the framework for DLL target. > > > > I don't see any benefit in this, particularly speaking of win32. > > The 'speaking of win32' is important. You're talking about the 'DLL > Hell'. I just searched the web for more info on this recurrent story. I > found enough articles on MSDN to understand why they stress the > uppercase 'H' in 'Hell'. It's not really our topic, but I suggest > someone sends the (100 lines) Linux ld.so man page to Redmond, they > really need to get a clue. > Well its not the place to start platform wars, and anti redmondism/macintoshism/linuxism is not welcome here ;-). > Now speaking of Unix, DLL support is mandatory for packaging. And I'll > support packaging (deb, rpm). It offers a number of features over the > static lib that nobody wants to loose : > > <boring Unixer experience> > > - Orthogonality : the only way to track bugs efficiently is to isolate > very module and do versionning. Nobody at Debian would like to force the > release of all NGL dependent packages when the NGL package itself is > updated for bugfixes reasons. Nor even try to understand which personal > taste of NGL a developer statically linked into its app. Nobody will > maintain such a thing. > I really don't see how you will be able to support al the possible NGL targets in one dll... I'd like to hear about this magic :-). (like maya, nogfx, etc...). > - Component-wise : distro and users keep the control, they can choose to > replace components, user older ones, or whatever they need. The best > example comes with binary-only software : VMWare 2.x was relying on a > glibc bug. When that glibc bug got fixed, VMWare stopped working. I > simply kept a copy of the buggy libc and ran VMWare against it with a > simple LD_LIBRARY_PRELOAD. If the libc was statically compiled in > VMWare, it would not have been possible for me to upgrade my kernel > below a known version. And it would have forced the VMWare people to do > all the libc bugtracking that RedHat, Mandrake, Suse and others do, > merge all those patches, and make frequent releases of VMWare. Nobody > wants to do that. > Yeah! Anybody does that, it's very user friendly :). It's simple, every user will understand this operation very well... Not! > - API stability and ABI guarantee. Since DLL releases imply binary > compatibility (and not source compatibility as for a static lib), this > ensure two thing for the developper : > > * ABI is preserved as long as the DLL major is unchanged (not related > to NGL's major), and further ABI updates can live happily side-by-side > > * API is very stable, since ABI compatibility implies that the only API > modifications are additions. > This can become very dangerous, some design flaws only become apparent over time and need a fix. I don't really want to get that much tied to legacy code if I need to change something. > </boring Unixer experience> > Well, you said it! :). > > > - How would manage all the different possible NGL target in a single dll? > > (with all the options: image codec inclusion, main loop support, maya > > support, unicode/mbcs, etc...?). If you can't manage to have all options in > > ONE dll we will have to cope with multiple versions at once which, once > > again, just kills the whole benefits of factorizing code in a dll. > > This is a packaging issue. The rule is 'compile in all stable features'. > In our case this makes dependencies on zlib, libpng, libjpeg and > freetype. The USE_WCHAR is an issue, but Qt has the same kind of > conditional compile. They made a choice : it was no_wchar for Qt2 > (developer were not interested), it his wchar for Qt3 (developers begged > for it !). Non-mainstream people (requiring stripped-down version, etc) > still compile Qt statically and happily. For instance I'll obviously > package libngl.deb with NOGFX turned off. > OK, so standard unix wil not get unicode support in NGL, right? > Again, this DLL thing is a feature, and it does not have to be supported > by win32. I just wish I could apt-get 'libngl' and 'libngl-devel' under > win32... Before I port dpkg to win32, I will at least support proper > packaging for Unix people :) > Ok, we agre on that: dll anywhere it can be supported, i.e. not in Win32. > Anyway, this will the subject of a next discussion : I need the Maya or > Netscape plugins classes to be subclasses of nglApp. Looking carefully > at nglApp and Maya plugin interface, it also occurs to me that it is > rather a wise design. Forcing me to do the right and proper hooks into > the event loop, etc. The #ifdef kludges in nglBaseApp should only deal > with _NOGFX_, adding _MAYAPLUGIN_ in here makes the code pas beau du > tout. > Can you elaborate on this? > > > And i'm not even talking about the pain it will be to support all the > > suplemental (and stupid) glue code to be able to export C++ symbols > > (exporting C function is easy, C++ is just a nightmare). > > If it's just a matter of appending that little constant blurb in front > of those symbols, I don't see the pb. Maintaining a .def file is clearly > not funny. And I don't see a linker option to export all symbols as a > default :(. > You where talking about very ugly kludges, here they come... > > > > > * We need a macro to choose the link method, what about USE_DLL ? > > > > That's only working for unices. Win32 still need explicit project > > description files. I'm planning to create as many ngl projects (dsps) as > > there are targets (app, maya plugin, no gfx app, etc...). > > OK, sounds heplful. Will just be not funny when we add a .cpp :) > I may have to automate the .dsp creation a bit soon, not only for the applications but for ngl too. > C++ is full of those little obligations that are obviously boring, but > nontheless worth the effort when you intend to make your code sharable > and portable. Ask Meeloo for the 'const and temporary instances pb' and > my frequent NUI fixes ! :). The NGL_API doesn't scare me one second. > I all ready hate it! > > > > I've just gone thru this pretty painfull process and finally got used to > > > stick MY_API everywhere (this is particularly crude on template classes / > > > stl-stuff witch needs to be typedef'ed to compile.. VC6 still eroneousliy > > > reports 'non dll interface' on those ones so you have to check it all by > > > hand...) > > Even if VC6 was smart enough to export templates automagically, you > would quicky find a platform/compiler combo that would'nt do it. Of > couse this is true in NGL context : satisfy compiler rants as long as it > does not impact on code (interface, size or performance). Meeloo and I > acquired code habits that don't break the build on both Linux and Win32 > in most commits. I said _most_ ;) > Well, we sometimes get to play ping pong on the CVS table but well... > Of course, the NGL user has no such constraints, if he wants to do ATL > over NGL, it's not my pb :) > It a SEP (Someone Else's Problem)! (you shall read The Hitchhicker's Guide To The Galaxy!!). MeeLoo Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17VCXn-000170-00 for <[EMAIL PROTECTED]>; Thu, 18 Jul 2002 07:46:16 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id B7BBBAFE3 for <[EMAIL PROTECTED]>; Thu, 18 Jul 2002 16:46:17 +0200 (CEST) Subject: Re: [NGL-devel] Re: [ngl-cvs] Renaming session... From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Thu Jul 18 07:47:04 2002 X-Original-Date: 18 Jul 2002 16:46:06 +0200 On Thu, 2002-07-18 at 13:11, Sebastien Metrot wrote: > In fact I don't much like NGL_APP_DECLARE, I would much prefer something > like NGL_APP_USE (just like we are "using" namespaces...) or something like > that (import?). Looks like Pascal or Perl :). Adopted. Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17VMek-0007uC-00 for <[EMAIL PROTECTED]>; Thu, 18 Jul 2002 18:34:07 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 00007AFE3 for <[EMAIL PROTECTED]>; Fri, 19 Jul 2002 03:34:10 +0200 (CEST) From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Subject: [NGL-devel] Wiki available Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Thu Jul 18 18:35:02 2002 X-Original-Date: 19 Jul 2002 03:33:51 +0200 Here : http://ngl.sourceforge.net/wiki/ Lorenzo has taken an option on a tutorial/howto writing, please refer to him for the Wiki maintenance (eheh :)). Received: from mallaury.noc.nerim.net ([62.4.17.82]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17ZamJ-0001aR-00 for <[EMAIL PROTECTED]>; Tue, 30 Jul 2002 10:27:23 -0700 Received: from zerodeux.net (mksp.net2.nerim.net [62.4.19.30]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 92CEC62D3D for <[EMAIL PROTECTED]>; Tue, 30 Jul 2002 19:26:42 +0200 (CEST) Message-ID: <[EMAIL PROTECTED]> From: Vincent Caron <[EMAIL PROTECTED]> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [NGL-devel] Log -> NGL core ? Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 30 10:28:03 2002 X-Original-Date: Tue, 30 Jul 2002 19:26:45 +0200 Lorenzo Pastrana wrote: > > En gros, l'objet de la discussion est de parvenir a isoler > complètement le noyau d'NGL (streams/files/strings/log) du reste > (App/Winz/Visuals etc..) pour pouvoir profiter des fonctionnalités bas > niveau sans recourir à toute l'artillerie du framework. Lorenzo asks for the possibility of using NGL as a tooklit (ie. NGL doesn't manage your application init and mainloop). -- There has always been a GL-independent target, called NOGFX : http://ngl.sourceforge.net/doc/ngl/classngl_application_base.html#_details The fact that NGL always own the main/WinMain (NOGFX mode or not) comes from its definition : 'framework', not 'toolkit'. You can forget to declare NGL's main (NGL_CREATE_APP macro's job), but in this case the application log and console are not available. NGL relies internally a lot on the logging facility (even if it's stripped down to errors+warnings in release mode). OUT() won't work. While it is possible to add some support to compile NGL as a 'toolkit' (removing nglApplication dependencies like logging), I don't see the point in doing so. It would be a shame to run NGL without its log and console support, I use it a lot (both as NGL developper and as NGL user) : http://ngl.sourceforge.net/doc/ngl/classngl_application_base.html#z3_9 ... Now if you consider that there are _toolkits_ which are 100 more advanced and portable than NGL (for things such as strings, threads, hashs, timers and such), why bothering with NGL ? NGL is 20% toolkit, 80% framework oriented (ie 80% of its class/components don't make sense taken individually). Use it as a framework. Admittedly, the string and file classes have grown pretty powerful, humility left apart :). But it was not designed from the ground to be standalone features, and I don't see a proper and easy way to support this kind of target. I mean without kluding the code and bringing the maintenance to a new level of nightmare. If you don't want the application's stuff, this is maybe related to the plugin stuff, read on. -- On the plugins side, we started on a slight 'conceptual' hack : we would like to make a relation between the application instance and a plugin instance. Note that the Maya plugin support (for Win32 and Linux) is a stub, or more exactly an application with its own init, log and console, but no main loop. This is really a quick and dirty hack. However the base idea was good, it was just lacking clear definitions and we were needing some experience. I believe we can solve those points : - optional dependency with this or that plugin SDK - mandatory DLL support for plugins - an exact definition of nglApplication's role in a plugin context After a meeting with the DLL Hell, here are some thoughts. Since there are multiple plugin instances in one application and only one App symbol, nglApplication's life cycle should be tied to the DLL's one. In other words, the application should be created upon DLL loading (automatic entry point à la __init, or provided by the plugin SDK, or hand-hacked by detecting a non-init'ed App), and release upon DLL unloading. The netscape plugin API has those notions : DLL loading/unloading, and plugin instance creation/destruction. The application would still hold global services (console, log, SetGamma(), etc), which is what we expect (one console popping for each plugin would drive the average user mad I guess). Now we need the entry points to create a plugin instance : class MayaPluginInstance { public: MayaPluginInstance(MObject& rObj); void OnCreation(); void OnDestruction(); }; class MayaPluginFactory : public nglApplication { public: bool OnCreatePlugin(MObject& rObj) { MayaPluginInstance* plugin = new MayaPluginInstance(Obj); return plugin != NULL && !plugin->GetError(); }; }; This is ackward/non-functionnal but it shows the schematics : * The specific MayaPlugin* class can be compiled in their own DLLs, _if_ the underlying nglApplication provides a mean to hook a different init and mainloop. Which is not a pb since we get to choose our entry points on a per-SDK basis. For example the NGL_CREATE_MAYAPLUGIN() would declare the MayaPluginFactory and triggers its entry point, which can totatlly ignore the nglApplication init and loop code. This is platform-dependent and implementation details. * The notion of plugin instance is exposed as it should be : this is what happens in real life, and we can't hide the fact that those instances run in the same process and memory space. It would be actually a crime to hide it, this knowledge is vital to develop correct plugins ! BTW, it let the user easily define means to communicate between its instances, or customize the instance creation, and so on. * This is very handy for packaging, since I can distribute ngl and ngl-mayaplugin as two separate DLLs under Unix. To compile a MayaPlugin target, you would juste include the proper header and link against libngl and libngl-maya. SDL uses this scheme (very) intensively. Of course this also helps for static compilation since keeping the Maya-code-only in Maya-classes-only spares a bunch of clumsy #ifdef scattered all around in NGL core. This would (should!) ideally not require any USE_MAYAPLUGIN macro. -- A little remark on NGL apps and plugins : the preceding story is true for plugins written over NGL, running in non-NGL apps (Maya, PhotoShop, 3DSMax, etc). If you write a NGL application and would like to support plugins, you have to provide a plugin SDK. And you'll be clever enough to write plugins with the NGL API too. But you don't have to play with the scheme exposed below : you already _are_ inside a NGL application ! This is where NGL compiled as a DLL shines, on all platforms : everything is compiled against NGL, linked against ngl.dll, the application does the NGL_CREATE_APP() et voilà ! -- On nglStringConv and MLang. Charset conversion is a separate component from nglString. This is meant to be pluggable. Read : http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ngl/ngl/src/core/win32/nglStringConv_mlang.cpp?rev=1.4&content-type=text/vnd.viewcvs-markup MBToWC+WCToMB won't do a decent job, sorry. Actually, if you want a very good charset conversion support, fetch one of the numerous portable iconv() implementation (I know at least 3 of them), define USE_ICONV and you're done. If you don't want charset conversion support, then just pretend there's no such support :). MLang is runtime detected (it's a COM object), it won't disturb you. And all encodings default use the locale's encoding in the NGL API, so it's transparent. Received: from zerodeux.net ([62.212.104.175]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17ZhJH-0006At-00 for <[EMAIL PROTECTED]>; Tue, 30 Jul 2002 17:25:52 -0700 Received: from localhost.localdomain (zerodeux.home [192.168.1.3]) by zerodeux.net (Postfix) with ESMTP id 47C57B3CB for <[EMAIL PROTECTED]>; Wed, 31 Jul 2002 02:25:50 +0200 (CEST) From: Vincent Caron <[EMAIL PROTECTED]> To: NGL devel ML <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Subject: [NGL-devel] Win32 DLL support Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 30 17:26:09 2002 X-Original-Date: 31 Jul 2002 02:25:35 +0200 A simple and least-intrusive proposal for DLL support under Windows. Lorenzo would test it in the next hour, he badly needs it ... * In ngl.h : #ifdef _WIN32_ ... #ifdef NGL_USE_DLL # ifdef NGL_BUILD # define NGL_API __declspec(dllexport) # else # define NGL_API __declspec(dllimport) # endif #endif ... #endif // _WIN32_ #ifndef NGL_API #define NGL_API #endif * Insert the NGL_API macro on every class declaration : class NGL_API nglApplication {}; (~20 items) * Update the NGL_APP_CREATE() and NGL_APP_USE() macros * Clone the current libngl.dsp/dsw as a libngl_dll.dsp/dsw Modify the link target (DLL!) Add NGL_USE_DLL and NGL_BUILD in preprocessor symbols Received: from meeloo.net ([62.4.18.112]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17ZmkK-0005DZ-00 for <[EMAIL PROTECTED]>; Tue, 30 Jul 2002 23:14:09 -0700 Received: from harry ([10.1.1.4]) by meeloo.net with smtp (Exim 3.35 #1 (Debian)) id 17ZmJI-0004yK-00 for <[EMAIL PROTECTED]>; Wed, 31 Jul 2002 07:46:12 +0200 Message-ID: <[EMAIL PROTECTED]> From: "Sebastien Metrot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Subject: Re: [NGL-devel] Win32 DLL support MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Tue Jul 30 23:15:02 2002 X-Original-Date: Wed, 31 Jul 2002 08:13:22 +0200 I warned you guys! I will not maintain this code... Here begins the nightmare :-(. MeeLoo ----- Original Message ----- From: "Vincent Caron" <[EMAIL PROTECTED]> To: "NGL devel ML" <[EMAIL PROTECTED]> Sent: Wednesday, July 31, 2002 2:25 AM Subject: [NGL-devel] Win32 DLL support > A simple and least-intrusive proposal for DLL support under Windows. > Lorenzo would test it in the next hour, he badly needs it ... > > > * In ngl.h : > > #ifdef _WIN32_ > ... > #ifdef NGL_USE_DLL > # ifdef NGL_BUILD > # define NGL_API __declspec(dllexport) > # else > # define NGL_API __declspec(dllimport) > # endif > #endif > ... > #endif // _WIN32_ > > #ifndef NGL_API > #define NGL_API > #endif > > > * Insert the NGL_API macro on every class declaration : > > class NGL_API nglApplication {}; > > (~20 items) > > > * Update the NGL_APP_CREATE() and NGL_APP_USE() macros > > > * Clone the current libngl.dsp/dsw as a libngl_dll.dsp/dsw > Modify the link target (DLL!) > Add NGL_USE_DLL and NGL_BUILD in preprocessor symbols > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Dice - The leading online job board > for high-tech professionals. Search and apply for tech jobs today! > http://seeker.dice.com/seeker.epl?rel_code=31 > _______________________________________________ > NGL-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/ngl-devel > Received: from mallaury.noc.nerim.net ([62.4.17.82]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17Zqmi-0004Ra-00 for <[EMAIL PROTECTED]>; Wed, 31 Jul 2002 03:32:52 -0700 Received: from zerodeux.net (mksp.net2.nerim.net [62.4.19.30]) by mallaury.noc.nerim.net (Postfix) with ESMTP id BF67A62D1F for <[EMAIL PROTECTED]>; Wed, 31 Jul 2002 12:32:45 +0200 (CEST) Message-ID: <[EMAIL PROTECTED]> From: Vincent Caron <[EMAIL PROTECTED]> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: [EMAIL PROTECTED] Subject: Re: [NGL-devel] Win32 DLL support References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=ngl-devel> Date: Wed Jul 31 03:33:04 2002 X-Original-Date: Wed, 31 Jul 2002 12:32:49 +0200 Sebastien Metrot wrote: > I warned you guys! I will not maintain this code... I don't really consider this to be 'code'. However syncing the .dsp's is extremely boring. I'm also having the pb here at work on a much larger scale, while trying to sync VC6 and VC7 project files on a 5,000 C++ files project. I think I'm going to write a tool to diff those different VC tastes or I'll go insane (go catch the little checkbox that says 'exclude from build' :(). Project description needs to be a standardized language some day, we're wasting an incredible amount of time with this bullshit.
