On Thu, 4 Oct 2012, Jon Trulson wrote: > It will take a it for it to propagate around the planet, but it's up > there. Here's the relevant, and somewhat brief portion of the HISTORY > file:
Congratulations to everyone! Here is a write up of my work in progress as well as some thoughts on the nearest future: tl;dr: - outstanding patches - complaints re XmPrivate.h - thoughts on libcsa interop - thoughts on versioning 83a60bb Add -Wno-write-strings to C++ compiler flags Posted 24 Sep 2012 to http://thread.gmane.org/gmane.comp.desktop.cde.devel/614 I understand that we want to have a nicer set of compiler specific options in config/cf to be able to set warnings set per compiler. On the principle of -Wno-write-strings I find the mailing list thread inconclusive :) Here is how FreeBSD introduces various levels of warnings for two compilers supported: http://svnweb.freebsd.org/base/head/share/mk/bsd.sys.mk?revision=240468 So the code grows from being WARNS=1 to WARNS=6 ready (WARNS=6 being -Wall and much more). Maybe we could have something similar and apply different "warning readiness" levels for various components (it will be difficult to do it for a whole tree). So something like WARNS = 3 could be added to those Imakefiles for components we already improved. Any thoughts? 296b1fb FreeBSD 10: Don't include <wchar.h> in dtksh Post 27 Sep 2012 to http://thread.gmane.org/gmane.comp.desktop.cde.devel/669 I don't know if our understanding is any better now. I am using this patch all the time because otherwise it won't build on FreeBSD 10.x I am now running. eb22182 Adobe Helvetica as -dt-interface system- Discussed: http://thread.gmane.org/gmane.comp.desktop.cde.devel/656/focus=683 Unpublished patch changing default font for -dt-interface system- from "-b&h-lucida-medium-r-normal-sans-*" to "-adobe-helvetica-medium-r-normal--*". I think there was a slight agreement on this mailing list that we can have it as the new default (at least for FreeBSD). Linux uses serif -b&h-lucidabright-* for this, maybe you would prefer a sans serif font too? 13fcf5e dtcm: 64bit work in progress Unpublished work in progress to fix some 64-bit issues in dtcm. Unfortunately, I think I took a slightly wrong approach there and I need to review those changes again: Just changing Dimension x; XtVaGetValues(..., MnSomeX, &x, ...); to XtArgVal x; XtVaGetValues(..., MnSomeX, &x, ...); doesn't always work as expected if some calculations are done on "x" later. In some cases I actually have to do XtArgVal x_; Dimension x; XtVaGetValues(..., MnSomeX, &x_, ...); x = (Dimension)x_; for example here: diff --git a/cde/programs/dtcm/dtcm/misc.c b/cde/programs/dtcm/dtcm/misc.c index 1a9bc2f..8168f08 100644 --- a/cde/programs/dtcm/dtcm/misc.c +++ b/cde/programs/dtcm/dtcm/misc.c @@ -1238,6 +1238,8 @@ ComputeMaxWidth( { Dimension width1, width2; + XtArgVal width1_, + width2_; Widget w[5]; int i; @@ -1250,16 +1252,18 @@ ComputeMaxWidth( w[4] = (Widget) NULL; XtVaGetValues(w1, - XmNwidth, &width1, + XmNwidth, &width1_, NULL); + width1 = (int)width1_; for (i = 1; w[i]; i++) { XtVaGetValues(w[i], - XmNwidth, &width2, + XmNwidth, &width2_, NULL); + width2 = (int)width2_; - if ((int)width2 > (int)width1) width1 = width2; + if (width2 > width1) width1 = width2; } return width1; I am using this patch now but it's probably not ready for the master. ---- * XmPrivate.h situation I am also *very* frustrated with the XmPrivate.h as it undermines my basic understanding of how make works. Maybe there is some problem with sub-second timestamping, I'm not sure. I would be grateful for any help to full understand how git and make get it right on my platform and wrong on Jon's. ---- I have two crashes outstanding: - crash of dtcreate upon exit due to double free(); #6 0x0000000000417e95 in free_Filetypedata (pFtD=0x8059e2320) at af_aux.c:570 570 if (pFtD->pszOpenCmd) XtFree(pFtD->pszOpenCmd); <jemalloc>: jemalloc_arena.c:173: Failed assertion: "bitmap_get(bitmap, &bin_inf o->bitmap_info, regind)" looks like we are freeing something we have already freeed. - dtfile crash: #0 0x000000000043d89f in UpdateHeaders (file_mgr_rec=0x5a5a5a5a5a5a5a5a, file_mgr_data=0x805cf9940, icons_changed=1 '\001') at FileMgr.c:2899 2899 if ((file_mgr_data->show_iconic_path == 0) != don't know how to reproduce, happens seldomly and is not very intrusive. Something heap-related too. ---- I have also abandoned some changes to libcsa because it seems tricky to get it right. It seems like that right now in my build (CSA_uint32) is long (64-bit) and not uint32_t despite what the name says. Trying to force it into 32 bits seems not a good idea either but I *hope* we are still interperable because those values got serialized into XDR "long" type. Anyway we need to check whether 64-bit dtcm can connect to 32-bit rpc.cmsd and vice versa, any volunteers? ----- I am going to look into how DtSvc detects CDE runtime version vs. compiled version because of this message: _DtXlateGetXlateEnv: Platform: FreeBSD; Execution Ver: 0; Compiled Ver: 10000 I think we could add something like __CDE_version to tell everyone the version of CDE running. Maybe even we could patch "dthello" or introduce "dtversion" utility to tell the release and git commit ID of the version running - I've seen already people reporting problems against 2.2.0a or 2.2.0b release that are already fixed in master. As we may soon run out of alphabet letters for our releases, what about introducing a Solaris-like scheme like CDE 2.2.0 2012/10 release? We could have also __CDE_version set to 20121001 or something like that. CDE-2.2.0-20121001 would also fit nicely into most packaging schemes until we are brave enough to bump it to 2.2.1 //Marcin ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
