SOLVED: Different results between glp_simplex() and gplsol
Problem solved. Stupid mistakes are the hardest to find, at least for me. A single column had a different bound specification in my call to glp_simplex(). Different problems, different results. Same problem, same results. Anyways, glpk is amazing. Thank you all developers for such fine work! -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute
Different results between glp_simplex() and gplsol
Hello, If I construct a matrix for a problem to feed glp_simplex() and run, [code] glp_smcp parm; glp_init_smcp(); int retval = glp_simplex(lp, ); double *x = calloc(vectorSize(data)+1, sizeof(double)); double z = glp_get_obj_val(lp); fprintf(stdout, "\nZ=%lf\n", z); [/code] I get the following: GLPK Simplex Optimizer 5.0 15 rows, 17 columns, 33 non-zeros 0: obj = 0.0e+00 inf = 1.168e+03 (4) 13: obj = 2.72000e+01 inf = 1.743e+02 (1) LP HAS NO PRIMAL FEASIBLE SOLUTION Z=27.20 But if I use the same matrix information to generate a CPLEX format file and run $ glpsol --lp cplex.lp -o out, I get: GLPSOL--GLPK LP/MIP Solver 5.0 Reading problem data from 'cplex.lp'... 15 rows, 17 columns, 33 non-zeros 36 lines were read GLPK Simplex Optimizer 5.0 15 rows, 17 columns, 33 non-zeros Preprocessing... 1 row, 2 columns, 2 non-zeros Scaling... A: min|aij| = 1.000e+00 max|aij| = 8.218e+02 ratio = 8.218e+02 GM: min|aij| = 1.000e+00 max|aij| = 1.000e+00 ratio = 1.000e+00 EQ: min|aij| = 1.000e+00 max|aij| = 1.000e+00 ratio = 1.000e+00 Constructing initial basis... Size of triangular part is 1 * 0: obj = 1.71400e+02 inf = 0.000e+00 (1) * 1: obj = 2.72000e+01 inf = 0.000e+00 (0) OPTIMAL LP SOLUTION FOUND Time used: 0.0 secs Memory used: 0.0 Mb (40400 bytes) Writing basic solution to 'out'... And the optimal solution is Z=27.2 I suppose I am missing something in the call to glp_simplex(), but what? This is the CPLEX format: MINIMIZE Z : + x11 + x12 + x13 + x14 SUBJECT TO r1 : + 821.80 x1 + 821.80 x2 + 821.80 x9 = 821.80 r2 : + 174.30 x3 + 174.30 x4 + 174.30 x10 = 174.30 r3 : + 27.20 x5 + 27.20 x6 = 27.20 r4 : + 144.20 x7 + 144.20 x8 = 144.20 r5 : + 821.80 x1 + 174.30 x3 - 27.20 x5 - 144.20 x7 + 1.00 x11 + 1.00 x13 - 1.00 x16 = 0.00 r6 : + 821.80 x2 + 174.30 x4 - 27.20 x6 - 144.20 x8 + 1.00 x12 + 1.00 x14 - 1.00 x17 = 0.00 r7 : - 28.00 x3 >= 0.00 r8 : - 40.00 x4 >= 0.00 r9 : - 7.20 x7 >= 0.00 r10 : - 34.70 x11 >= 0.00 r11 : - 46.70 x12 >= 0.00 r12 : - 0.165000 x1 >= 0.00 r13 : - 0.232000 x3 >= 0.00 r14 : - 0.067000 x4 >= 0.00 r15 : - 0.016000 x6 >= 0.00 BOUNDS 0 <= x1 <= 1 0 <= x2 <= 1 0 <= x3 <= 1 0 <= x4 <= 1 0 <= x5 <= 1 0 <= x6 <= 1 0 <= x7 <= 1 0 <= x8 <= 1 0 <= x9 <= 1 0 <= x10 <= 1 0 <= x11 0 <= x12 0 <= x13 0 <= x14 0 <= x15 0 <= x16 0 <= x17 END And this is the matrix information from which the CPLEX format is constructed: \* GLPK matrix: \* ia[1]=1, ja[1]=1, ra[1]=821.80 \* ia[2]=1, ja[2]=2, ra[2]=821.80 \* ia[3]=1, ja[3]=9, ra[3]=821.80 \* ia[4]=2, ja[4]=3, ra[4]=174.30 \* ia[5]=2, ja[5]=4, ra[5]=174.30 \* ia[6]=2, ja[6]=10, ra[6]=174.30 \* ia[7]=3, ja[7]=5, ra[7]=27.20 \* ia[8]=3, ja[8]=6, ra[8]=27.20 \* ia[9]=4, ja[9]=7, ra[9]=144.20 \* ia[10]=4, ja[10]=8, ra[10]=144.20 \* ia[11]=5, ja[11]=15, ra[11]=0.00 \* ia[12]=5, ja[12]=1, ra[12]=821.80 \* ia[13]=5, ja[13]=3, ra[13]=174.30 \* ia[14]=5, ja[14]=11, ra[14]=1.00 \* ia[15]=5, ja[15]=13, ra[15]=1.00 \* ia[16]=5, ja[16]=5, ra[16]=-27.20 \* ia[17]=5, ja[17]=7, ra[17]=-144.20 \* ia[18]=5, ja[18]=16, ra[18]=-1.00 \* ia[19]=6, ja[19]=2, ra[19]=821.80 \* ia[20]=6, ja[20]=4, ra[20]=174.30 \* ia[21]=6, ja[21]=12, ra[21]=1.00 \* ia[22]=6, ja[22]=14, ra[22]=1.00 \* ia[23]=6, ja[23]=6, ra[23]=-27.20 \* ia[24]=6, ja[24]=8, ra[24]=-144.20 \* ia[25]=6, ja[25]=17, ra[25]=-1.00 \* ia[26]=7, ja[26]=3, ra[26]=-28.00 \* ia[27]=8, ja[27]=4, ra[27]=-40.00 \* ia[28]=9, ja[28]=7, ra[28]=-7.20 \* ia[29]=10, ja[29]=11, ra[29]=-34.70 \* ia[30]=11, ja[30]=12, ra[30]=-46.70 \* ia[31]=12, ja[31]=1, ra[31]=-0.165000 \* ia[32]=13, ja[32]=3, ra[32]=-0.232000 \* ia[33]=14, ja[33]=4, ra[33]=-0.067000 \* ia[34]=15, ja[34]=6, ra[34]=-0.016000 What am I missing in the glp_simplex call? Or maybe I should just stick with creating the cplex format and do an execlp()? Any clues are warmly appreciated. -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute
Re: [DuMux] Oil-gas compositional simulation in DuMux
Yes, Dmitry, please do consider Bernd's suggestions. It would be appreciated by more than one. Best regards On Fri, Mar 18, 2022, 2:24 AM Dmitry Pavlov wrote: > Bernd, > > > Thank you. I will check with my managers regarding what I can do about > publishing the code. The completeFluidState in my code is not a branch, but > a method in a dedicated VolumeVariables variant which is assigned to the > Problem via TypeTag. One "potential complication" that I can see is that > the code in its present form is not going to be accepted into DuMux source > because it does not comply with DuMux's C++ guidelines (that happened > before with my merge requests). So either I will have to re-write it, or > someone else will, or it will stay as an example/prototype outside DuMux > source tree. > > > To elaborate on my statement about complications with 2pnc PVS model: > imagine that at one moment, you have a two-phase configuration: > > > pressure, saturation, (n-2) mole fractions in one of the phases > > > and then you run the Newton method, and then the Newton method orders to > increase the pressure, leaving other variables intact: > > > pressure + delta, saturation, (n-2) mole fractions in one of the phases > > > It can happen that with the increased pressure, the two-phase > configuration is to become one-phase. It is very hard, if possible, to > figure that basing just on (n-2) mole fractions and the saturation. The > saturation without the (original, two-phase-compatible) pressure is > meaningless. And the old value or pressure is "lost" at this point. How to > even guess the total mole fractions in this situation? I do not know. > > > I imagine that a very intricate relay between the Newton method and > PrimaryVariableSwitch could, in principle, allow to slowly approach the > phase transition point and then change the primary variables... but there > is no need to do that in presence of "classic" flash that works so well and > converges so well. (I also have to say that figuring out the fluid state > from the "pressure, saturation, n-2 mole fractions" is a big convergence > pain). > > > > Best regards, > > > Dmitry > > > > > On 3/18/22 09:57, Flemisch, Bernd wrote: > > Hi Dmitry, > > > thank you for your report, this is very valuable! > > > It would be even more valuable and highly appreciated if you decide to add > your model to DuMux. As far as I can see, this would in essence add the > Michelsen test and your flash calculation. And the completeFluidState > method would branch depending on whether the traditional "PVS" or the new > "flash" model is used. Right? Or do you see potential complications? > > > I consider your statement > > "The primary variables. Those must be the pressure and n-1 (overall) mole > fractions. I do not think that it is possible at all to implement a > two-phase compositional model with the usual primary variables of the 2pnc > model" > > very bold. The 2pnc PVS model is standard which has been used > successfully not only in DuMux to simulate two-phase compositional flow for > many years. > > > Nevertheless, I certainly acknowledge the fact that a flash-based model > might be superior for particular applications. With the drawback on > computational performance due to the more expensive flash calculations for > one Newton step. > > > In total, I would heartily encourage you to contribute your model! > > > Kind regards > > Bernd > > > -- > _ > > Bernd Flemisch > IWS, Universität Stuttgart phone: +49 711 685 69162 > Pfaffenwaldring 61 email: be...@iws.uni-stuttgart.de > D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ > _ > -- > *Von:* DuMux > im Auftrag von Dmitry Pavlov > > *Gesendet:* Donnerstag, 17. März 2022 23:20:09 > *An:* dumux@listserv.uni-stuttgart.de > *Betreff:* [DuMux] Oil-gas compositional simulation in DuMux > > > Hello, > > This is for anybody who will be wondering someday whether the two-phase > oil-gas compositional model is doable in DuMux. The short answer is yes. > > The numerical algorithms required for such a model are described in many > sources (e.g. [1]) and implemented in ECLIPSE and a lot of other programs, > including the open-source MRST [2]. > > > Now, what is required for implementing the two-phase compositional model > in DuMux: > > 1. The primary variables. Those must be the pressure and n-1 (overall) > mole fractions. I do not think that it is possible at all to implement a > two-phase compositional model with the usual primary variables of the 2pnc > model [3] (pressure, saturation, n-2 mole fractions). But the good news is > that DuMux, for the most part, does not care about what is stored in the > primary variables. So it is possible to just treat 2pnc's primary variables > as the pressure and n-1 (overall) mole fractions. The only thing that must
[DuMuX] question for dumux-gentoo users
Hi, I just updated my gentoo box to 17.1 desktop profile and everything works fine, except for dumux. I get a crash which seems to be an invalid pointer to a basic string. This crash did not occur with gcc-8.2 but is now happening with gcc-9.2. Does anyone have a similar problem with gcc-9.2? Or maybe it is just an issue in my problem isource code which is handled differently in 9.2 versus 8.2? Opinions? Below I list the crash output which occurs in the pthread library (which works fine with other programs). best regards and happy new year! [cancer:23561] *** Process received signal *** [cancer:23561] Signal: Segmentation fault (11) [cancer:23561] Signal code: Address not mapped (1) [cancer:23561] Failing at address: 0x3 [cancer:23561] [ 0] /lib64/libpthread.so.0(+0x14680)[0x7fcb327ce680] [cancer:23561] [ 1] /lib64/libc.so.6(+0xa9f85)[0x7fcb31823f85] [cancer:23561] [ 2] /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so.6(_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_+0x98)[0x7fcb31c1dd48] [cancer:23561] [ 3] /home/GIT/LSWF/projects/lswi-dumux-n//build-cmake/src/lswi-dumux-n(_ZN5Dumux11EpisodeDataINS_10Properties4TTag14LSWFBoxTypeTagEE12getStageDataEiPPKc+0x307)[0x55765072a4c3] [cancer:23561] [ 4] /home/GIT/LSWF/projects/lswi-dumux-n//build-cmake/src/lswi-dumux-n(_ZN5Dumux11EpisodeDataINS_10Properties4TTag14LSWFBoxTypeTagEE4initEPPKc+0x8f)[0x557650719a7b] [cancer:23561] [ 5] /home/GIT/LSWF/projects/lswi-dumux-n//build-cmake/src/lswi-dumux-n(_ZN5Dumux8LswiDataINS_10Properties4TTag14LSWFBoxTypeTagEEC1Ev+0x86)[0x557650706328] [cancer:23561] [ 6] /home/GIT/LSWF/projects/lswi-dumux-n//build-cmake/src/lswi-dumux-n(_ZN5Dumux21LSWF2pncSpatialParamsINS_10Properties4TTag14LSWFBoxTypeTagEEC1ESt10shared_ptrIKNS_17BoxFVGridGeometryIdN4Dune8GridViewINS7_25DefaultLeafGridViewTraitsIKNS7_8YaspGridILi2ENS7_22EquidistantCoordinatesIdLi2ELb0ENS_28BoxDefaultGridGeometryTraitsISG_NS_19DefaultMapperTraitsISG_NS7_35MultipleCodimMultipleGeomTypeMapperISG_NS7_4Impl14MCMGFailLayoutEEESM_EEE+0x2c)[0x55765074514e] -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
[DuMuX] replacing outflow BC condition in legacy 2.12 code
Hello all, I understand the the boundary type specification"outflow" has been removed from the current version of DuMux. I see that an outflow is now to be specified by constructiong the element solution, evaluating the gradient and calculating the flux. In an example I see that the templates for elementSolution and evalGradients are used. I am quite sure that a similar approach can be used somehow in 2.12 if I knew exactly where to start looking. Am I right? If so, where should I start looking? best regards, Edscott I -- ---- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: GTK+ doesn't track motion of DND file from desktop
Check the version with which you gtk desktop and applications are compiled with. DnD worked quite erratically for me in 3.22, and seems to be more or less stable in 3.24, but applications compiled with 2.24 which used to work fine with those from 3.18 now will ignore drops from 3.24 apps. In the gtk developers' log, I've noticed that work was done on DnD. There might be some updates to 2.24 to maintain compatibility, but I would not hold my breath. El mar., 6 de nov. de 2018 a la(s) 09:28, Zdravetz via gtk-app-devel-list ( gtk-app-devel-list@gnome.org) escribió: > > > > My initialization of the destination widget is as such: > > > GtkTargetList* target_list = gtk_target_list_new(NULL, 0); > > > gtk_target_list_add_image_targets(target_list, 0 /* ALL_IMAGES */, > FALSE); > gtk_target_list_add_uri_targets(target_list, 1 /* TEXT_URI */) ; > > > gtk_drag_dest_set(GTK_WIDGET(gui.event_dropbox), 0, NULL, 0, > GDK_ACTION_DEFAULT); > gtk_drag_dest_set_target_list(GTK_WIDGET(gui.event_dropbox), > target_list); > gtk_drag_dest_set_track_motion(GTK_WIDGET(gui.event_dropbox), TRUE); > > > Doing so, if I DND text from within the application it tracks motion in the > `drag-motion` event, but doesn't seem to invoke this signal at all > when dealing with files from the desktop. It invokes all other signals as > expected, beside `drag-motion` and `drag-leave`. > > > I am very exhausted from trying to figure this out, so maybe some of you > can? > > > > > - > > П.П. Искаш сайт? Направи си, лесно е! Отиди на www.superhosting.bg и > избери най-доброто име за него. Започни сега със СуперХостинг.БГ! > > https://www.superhosting.bg/?utm_source=mail.bg_medium=cpm_content=mail_header_campaign=campaign2018 > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [DuMuX] SOLVED memory corruption in brookscorey.hh?
The problem seems to be a bug in gcc or gdb, because it happens with gcc-6.3.1/gdb-7.12.1 and no longer occurs in gcc-8.2./gdb-8.1.1. And it seems to only be related to gdb since when the program runs without gdb, the results of the simulation are identical to that which results from the executable created with gcc-8.2. Anyways I've created and uploaded a docker image with dumux-2.12 with gcc-8.2 at the docker hub, The image is impmx/dumux-2.12:20180823 if anyone is interested. The docker files for the creation can be accessed at url = g...@github.com:edscott/dumux.git best regards! El mié., 22 de ago. de 2018 a la(s) 16:33, Christoph Grüninger ( f...@grueninger.de) escribió: > Hi Edscott, > you are right, you have to recompile the complete Dune stack with Clang > and the flags for the desired saninitzer. When you use a different build > directory, it is easy to switch back to your GCC-built stack. > > Hope this helps, > Christoph > > Am 22.08.2018 um 18:23 schrieb Edscott Wilson: > > Hi, Christoph, > > > > clang sounds good. I'll give it a try, But will I have to recompile dune > > with clang or will it be compatible with gcc generated .a libraries? > > > > Best Regards, > > > > Edscott > > -- > Unfortunately, plots are notoriously hard to get right. Partly, the > default settings of programs like gnuplot or Excel are to blame for > this since these programs make it very convenient to create bad plots. > -- Till Tantau, "The TikZ and PGF Packages" > ___ > Dumux mailing list > Dumux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMuX] memory corruption in brookscorey.hh?
Hi, Christoph, clang sounds good. I'll give it a try, But will I have to recompile dune with clang or will it be compatible with gcc generated .a libraries? Best Regards, Edscott El mar., 21 de ago. de 2018 a la(s) 17:10, Christoph Grüninger ( f...@grueninger.de) escribió: > Hi Edscott, > give AddressSanitizer a try, it is a great tool to find such thing you > describe. Further MemorySanitizer and Undefined Behavior Sanitizer might > turn out to be helpful, too. My best experience with these tools were > when I used the latest Clang compiler. Some of them work with recent > versions of GCC very well, too. > Valgrind might be worth a try. But it has more false positives and the > output is more difficult to understand. > > Kind regards, > Christoph > > Am 21.08.2018 um 18:10 schrieb Edscott Wilson: > > OK. > > I'll dig into the matter a bit further to see if I can solve where the > > problem arises. It might be an incorrect cast somewhere that screws up > > memory locations. > > > > Best regards, > > > > Edscott > > > > > > 2018-08-17 15:31 GMT-05:00 Flemisch, Bernd > > > <mailto:bernd.flemi...@iws.uni-stuttgart.de>>: > > > > Hi Edscott, > > > > can you please open an issue at > > https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues > > <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues> ? > > Due to holiday season, it might take us some time to look at this. > > By opening an issue, it won't be forgotten. > > > > Kind regards > > Bernd > > > > Von: Edscott Wilson > > Gesendet: Donnerstag, 16. August, 23:47 > > Betreff: [DuMuX] memory corruption in brookscorey.hh? > > An: DuMuX User Forum > > > > > > This is weird and should not be happening. I explain. > > > > While debugging a generalized Dirichlet type problem, I am > > encountering a problem with the BrooksCorey material law > > (dumux/material/fluidmatrixinteractions/2p/brookscorey.hh). > > > > Here is the code from brookscorey.hh: > > > > 181 using std::min; > > 182 using std::max; > > 183 > > 184 swe = min(max(swe, 0.0), 1.0); // the equation below > > is only defined for 0.0 <= sw <= 1.0 > > 185 > > 186 return pow(swe, 2.0/params.lambda() + 3); > > 187 } > > > > Inserting a break before the min(max()) call, I examine the value of > > swe: > > > > Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey > Dumux::RegularizedBrooksCoreyParams >::krw (params=..., > > swe=6.9319619419652626e-17) at > > > > /opt/dune/include/dumux/material/fluidmatrixinteractions/2p/brookscorey.hh:184 > > 184 swe = min(max(swe, 0.0), 1.0); // the equation below > > is only defined for 0.0 <= sw <= 1.0 > > (gdb) print swe > > $11 = 6.9319619419652626e-17 > > > > > > Then I step over the min(max() call and re-examine swe and get a > > corrupted value: > > > > (gdb) next > > 186 return pow(swe, 2.0/params.lambda() + 3); > > (gdb) print swe > > $12 = -3.9159195083267944e+240 > > > > Stepping into the min(max()) function I see that the value which > > should be "1.0" arrives corrupted: > > > > (gdb) > > std::min (__a=@0x7fffae00: 6.9319619419652626e-17, > > __b=@0x7fffae10: -3.9159195083267944e+240) > > at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 > > 200 if (__b < __a) > > (gdb) print __b > > $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 > > > > > > Looks like the "1.0" is being placed on the stack and being > > optimized away after the max() part completes. > > > > Doing some changes to the code and doing the simple eff2abs law > > conversion within the regularizedbrooksCorey class template, the > > problem disappears, as the following gdb output shows: > > > > Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV > Dumux::RegularizedBrooksCoreyVParams >::krw (params=..., > > swe=6.9319619419652626e-17, iS=4.22627533) at > > /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 > > 91 swe = min(max(swe, 0.0), 1.0); // the equation below > > is only defin
Re: [DuMuX] memory corruption in brookscorey.hh?
Hi Timo, Problem occurs exactly the same way with or without -O0. In order to test whether problem only occurs with gdb, I add line 185 and run. brookscorey.hh: 184swe = min(max(swe, 0.0), 1.0); // the equation below is only defined for 0.0 <= sw <= 1.0 185std::cerr<<"swe returns with: "< Dear Edscott, > > what was your actual problem you are trying to solve? Is this a problem > with Dumux? The code you are showing looks perfectly fine to me. > > Or was this just occurring during debugging? Your comments sound like you > are debugging optimized code. If yes, is there any problem if the code is > compiled with -O0? Not all symbols are always defined if there are > optimized away so it might look like this. > > Timo > > > > Viele Grüße, > Timo > Am 21.08.2018 um 20:40 schrieb Edscott Wilson < > edscott.wilson.gar...@gmail.com>: > > OK. > I'll dig into the matter a bit further to see if I can solve where the > problem arises. It might be an incorrect cast somewhere that screws up > memory locations. > > Best regards, > > Edscott > > > 2018-08-17 15:31 GMT-05:00 Flemisch, Bernd < > bernd.flemi...@iws.uni-stuttgart.de>: > >> Hi Edscott, >> >> can you please open an issue at >> https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues ? Due >> to holiday season, it might take us some time to look at this. By opening >> an issue, it won't be forgotten. >> >> Kind regards >> Bernd >> >> Von: Edscott Wilson >> Gesendet: Donnerstag, 16. August, 23:47 >> Betreff: [DuMuX] memory corruption in brookscorey.hh? >> An: DuMuX User Forum >> >> >> This is weird and should not be happening. I explain. >> >> While debugging a generalized Dirichlet type problem, I am encountering a >> problem with the BrooksCorey material law >> (dumux/material/fluidmatrixinteractions/2p/brookscorey.hh). >> >> Here is the code from brookscorey.hh: >> >> 181 using std::min; >> 182 using std::max; >> 183 >> 184 swe = min(max(swe, 0.0), 1.0); // the equation below is >> only defined for 0.0 <= sw <= 1.0 >> 185 >> 186 return pow(swe, 2.0/params.lambda() + 3); >> 187 } >> >> Inserting a break before the min(max()) call, I examine the value of swe: >> >> Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey> Dumux::RegularizedBrooksCoreyParams >::krw (params=..., >> swe=6.9319619419652626e-17) at >> /opt/dune/include/dumux/material/fluidmatrixinteractions/2p/brookscorey.hh:184 >> 184 swe = min(max(swe, 0.0), 1.0); // the equation below is >> only defined for 0.0 <= sw <= 1.0 >> (gdb) print swe >> $11 = 6.9319619419652626e-17 >> >> >> Then I step over the min(max() call and re-examine swe and get a >> corrupted value: >> >> (gdb) next >> 186 return pow(swe, 2.0/params.lambda() + 3); >> (gdb) print swe >> $12 = -3.9159195083267944e+240 >> >> Stepping into the min(max()) function I see that the value which should >> be "1.0" arrives corrupted: >> >> (gdb) >> std::min (__a=@0x7fffae00: 6.9319619419652626e-17, >> __b=@0x7fffae10: -3.9159195083267944e+240) >> at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 >> 200 if (__b < __a) >> (gdb) print __b >> $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 >> >> >> Looks like the "1.0" is being placed on the stack and being optimized >> away after the max() part completes. >> >> Doing some changes to the code and doing the simple eff2abs law >> conversion within the regularizedbrooksCorey class template, the problem >> disappears, as the following gdb output shows: >> >> Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV> Dumux::RegularizedBrooksCoreyVParams >::krw (params=..., >> swe=6.9319619419652626e-17, iS=4.22627533) at >> /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 >> 91 swe = min(max(swe, 0.0), 1.0); // the equation below is >> only defined for 0.0 <= sw <= 1.0 >> (gdb) step >> std::max (__a=@0x7fffade0: 6.9319619419652626e-17, >> __b=@0x7fffadf8: 0) at /usr/include/c++/6.3.1/bits/stl_algobase.h:224 >> 224 if (__a < __b) >> (gdb) next >> 226 return __a; >> (gdb) >> 227 } >> (gdb) >> Dumux::BrooksCoreyV >> >::krw (params=..., swe=6.93
Re: [DuMuX] memory corruption in brookscorey.hh?
OK. I'll dig into the matter a bit further to see if I can solve where the problem arises. It might be an incorrect cast somewhere that screws up memory locations. Best regards, Edscott 2018-08-17 15:31 GMT-05:00 Flemisch, Bernd < bernd.flemi...@iws.uni-stuttgart.de>: > Hi Edscott, > > can you please open an issue at https://git.iws.uni-stuttgart. > de/dumux-repositories/dumux/issues ? Due to holiday season, it might take > us some time to look at this. By opening an issue, it won't be forgotten. > > Kind regards > Bernd > > Von: Edscott Wilson > Gesendet: Donnerstag, 16. August, 23:47 > Betreff: [DuMuX] memory corruption in brookscorey.hh? > An: DuMuX User Forum > > > This is weird and should not be happening. I explain. > > While debugging a generalized Dirichlet type problem, I am encountering a > problem with the BrooksCorey material law (dumux/material/ > fluidmatrixinteractions/2p/brookscorey.hh). > > Here is the code from brookscorey.hh: > > 181 using std::min; > 182 using std::max; > 183 > 184 swe = min(max(swe, 0.0), 1.0); // the equation below is > only defined for 0.0 <= sw <= 1.0 > 185 > 186 return pow(swe, 2.0/params.lambda() + 3); > 187 } > > Inserting a break before the min(max()) call, I examine the value of swe: > > Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey RegularizedBrooksCoreyParams >::krw (params=..., > swe=6.9319619419652626e-17) at /opt/dune/include/dumux/material/ > fluidmatrixinteractions/2p/brookscorey.hh:184 > 184 swe = min(max(swe, 0.0), 1.0); // the equation below is > only defined for 0.0 <= sw <= 1.0 > (gdb) print swe > $11 = 6.9319619419652626e-17 > > > Then I step over the min(max() call and re-examine swe and get a corrupted > value: > > (gdb) next > 186 return pow(swe, 2.0/params.lambda() + 3); > (gdb) print swe > $12 = -3.9159195083267944e+240 > > Stepping into the min(max()) function I see that the value which should be > "1.0" arrives corrupted: > > (gdb) > std::min (__a=@0x7fffae00: 6.9319619419652626e-17, > __b=@0x7fffae10: -3.9159195083267944e+240) > at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 > 200 if (__b < __a) > (gdb) print __b > $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 > > > Looks like the "1.0" is being placed on the stack and being optimized away > after the max() part completes. > > Doing some changes to the code and doing the simple eff2abs law conversion > within the regularizedbrooksCorey class template, the problem disappears, > as the following gdb output shows: > > Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV Dumux::RegularizedBrooksCoreyVParams >::krw (params=..., > swe=6.9319619419652626e-17, iS=4.22627533) at > /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 > 91 swe = min(max(swe, 0.0), 1.0); // the equation below is > only defined for 0.0 <= sw <= 1.0 > (gdb) step > std::max (__a=@0x7fffade0: 6.9319619419652626e-17, > __b=@0x7fffadf8: 0) at /usr/include/c++/6.3.1/bits/stl_algobase.h:224 > 224 if (__a < __b) > (gdb) next > 226 return __a; > (gdb) > 227 } > (gdb) > Dumux::BrooksCoreyV > >::krw (params=..., swe=6.9319619419652626e-17, iS=4.22627533) > at /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:92 > 92 return pow(swe, 2.0/params.lambda(iS) + 3); > (gdb) print swe > $18 = 6.9319619419652626e-17 > > > Opinions? > > Could there be something amiss in the EffToAbsLaw class template? > > Or could it be a gcc bug? (using "gcc (GCC) 6.3.1 20170109" and "GNU gdb > (GDB) 7.12.1"). > > I tried to use gdb within a docker container with "gcc (GCC) 7.3.1 > 20180312" and "GNU gdb (GDB) 8.1" but I get: > > (gdb) run > Starting program: /home/dumux/projects/lswf-chem11-USE_BC-CACO3_CASO4_ > MGCO3-SIMPLIFIED-UMF/build-cmake/src/lswf-chem11 -ParameterFile > ../SW-b.input > warning: Error disabling address space randomization: Operation not > permitted > warning: Could not trace the inferior process. > Error: > warning: ptrace: Operation not permitted > During startup program exited with code 127. > > Has anybody had luck debugging with gdb within a docker container? > > > The full g++ compiler command is as follows: > > /usr/bin/c++ -Wno-deprecated -ggdb -I/home/dumux/problems/lswf-chem11 > -I/home/dumux/include -I/home/dumux -I/opt/dune/include -DUSE_BC > -DCACO3_CASO4_MGCO3 -DSIMPL
[DuMuX] bug in 2.12 constraintsolvers/CMakeFiles.txt
Hi Timo, Seems like a mistake in dumux/dumux/material/constraintsolvers/CMakeFiles.txt, because files that were present in 2.11 are gone in 2.12 but not removed from CMakeFiles.txt, which causes the make install to fail when the dumux repository is cloned from branch releases/2.12 during construction of the docker image. I worked around it with: sed 's/computefromreferencephase2pnc.hh//' dumux/dumux/material/constraintsolvers/CMakeLists.txt | sed 's/computefromreferencephase2pncmin.hh//' | sed 's/compositionfromfugacities2pncmin.hh//' Best regards, Edscott -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
[DuMuX] new archlinux based docker images
Hi all, I've just uploaded docker images for dumux-2.12 based on archlinux in the docker hub repository https://hub.docker.com/r/impmx/dumux-2.12. Later I will be uploading an image with an example on how to work an example by means of python script, which I have now fully tested. In the full description of the impmx/docker-2.12 you will find the script with which to fire the containers. Sandboxed users should use the tag latest or user, while modifications to the system should be done with the root tag. Docker files to create the images are also included in /usr/local/src for reference. BTW, Timo, I've tested the paraview in the dumux/release-2.12 image on an Ubuntu12.04 box, and the initial window opens, but on mouse action the application crashes. I suppose it is because paraview wants to access the video card directly and this is different on different boxes. Anyways, we prefer to run paraview after the simulation is done on the host machine, and that is where the shared directory comes into play. best regards, Edscott -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMuX] DuMux and Docker
Hi Timo,
I can now access dumux-repositories/dumux-docker without any problems,
thanks!. What I find is that graphics support is mostly defined in the
dumux start script. But graphics does not start on an archlinux box unless
XAUTHORITY permission is granted for the docker container. This can be done
by applying the following patch to the startup script.
--- dumux.sh2018-01-17 15:43:42.818240499 -0600
+++ dumux-new.sh2018-01-17 15:43:58.718209994 -0600
@@ -29,11 +29,14 @@
open()
{
IMAGE="$1"
-
+XAUTH=/tmp/.docker.xauth
+`xauth nlist $DISPLAY | sed 's/^//' | xauth -f $XAUTH nmerge -`
COMMAND="docker create -i -t \
-e HOST_UID=$(id -u $USER) \
-e HOST_GID=$(id -g $USER) \
-e DISPLAY=$DISPLAY \
+ -v $XAUTH:$XAUTH \
+ -e XAUTHORITY=$XAUTH \
--device /dev/dri \
-v $SHARED_DIR_HOST:$SHARED_DIR_CONTAINER \
-v /tmp/.X11-unix:/tmp/.X11-unix:rw \
With that, paraview with initially opens, but then crashes with the
following:
ERROR: In
/build/paraview-arsa8T/paraview-5.0.1+dfsg1/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx,
line 394
vtkXOpenGLRenderWindow (0x20978a0): Could not find a decent visual
ERROR: In
/build/paraview-arsa8T/paraview-5.0.1+dfsg1/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx,
line 613
vtkXOpenGLRenderWindow (0x20978a0): GLX not found. Aborting.
Aborted (core dumped)
I guess that's because the host is an Archlinux box which is quite a deal
more updated than the debian container, maybe?
Nonetheless, since vtk files are shared and viewed after simulation
completes, we have no problem with using paraview on the docker host.
What we really want is to view gnuplot graphics as the simulation proceeds,
and that is now possible.
Using the shared X11 socket and XAUTHORIZATION stuff, we can now open
xterms from our container and view simulation graphs with gnuplot as the
computation proceeds. Still, installing gnuplot from package brings in too
much stuff to the container and fonts are missing. As soon as I fix those
details I will upload the docker image to the docker hub.
What follows is to create a dumux-3.0r1 image because we are very
interested in seeing how the assembler has been improved (the assembler
takes the lion's share of cpu time in our problem).
best regards,
Edscott
2018-01-17 3:49 GMT-06:00 Timo <koch_t...@hotmail.com>:
>
>
> Am 16.01.2018 um 20:58 schrieb Edscott Wilson <
> edscott.wilson.gar...@gmail.com>:
>
> Hi all,
>
> I've removed the docker container I mentioned in the previous post, as
> there was a mistake in the build. In that build the dune version was 2.6,
> which means it does compile with dumux-2.12, but when you try to link a
> problem, errors occur due to changes in the vtkwriter and other places.
> I've now uploaded a new docker with dumux-2.12 and dune-2.5 and tested it
> correctly. The "standard" way to enter this docker container is with the
> following script:
>
>
> Hi Edscott,
>
> Dune 2.6 was not released yet when Dumux 2.12 was released so it is not
> supported. The Dumux 3.0-alpha release however is compatible.
>
>
> #!/bin/sh
> version='dumux-2.12c'
> default=`pwd`
> echo "Welcome to $version (docker)"
> #read -p " Please specify src directory [$default]: " SRC
> if test x$SRC = x; then
> SRC=$default
> fi
> echo "Shared directory /home/dumux set to $SRC"
> echo "Creating docker container"
> docker rm $version-container
> docker create -ti -e USER=$USER -e HOST_GID=$(id -g $USER) -e
> HOST_UID=$(id -u $USER) -e SRC=$SRC -v $SRC:/home/dumux
> --name=$version-container --hostname=docker impmx/lswf:$version
> #mkdir "$SRC/output"
> exec docker start -a -i $version-container
>
> This opens the docker container with the same user as the invoker with
> read/write privileges in the current and shared directory. If you open the
> container without the enironment defined in the script, the user will be
> root and no shared directories. Dune and dumux are installed in /opt and
> the path and compile flags are ser accordingly. This is to keep user
> problems separate from dune/dumux core, as is customary for distributed
> software.
>
>
> This is one approach especially when you are only working with release
> versions. Another approach that is by far the more popular in the Dune
> community is creating your own dune-module. This way the user files are
> always separated from the main program. Then it doesn't matter if you
> decide to compile Dune from source (the you can keep up with the newest
> changes) or even install Dune with the Debian packages.
>
> User does not have write permissions in opt, but since the include path
> can be defi
Re: [DuMuX] DuMux and Docker
Hi all, I've removed the docker container I mentioned in the previous post, as there was a mistake in the build. In that build the dune version was 2.6, which means it does compile with dumux-2.12, but when you try to link a problem, errors occur due to changes in the vtkwriter and other places. I've now uploaded a new docker with dumux-2.12 and dune-2.5 and tested it correctly. The "standard" way to enter this docker container is with the following script: #!/bin/sh version='dumux-2.12c' default=`pwd` echo "Welcome to $version (docker)" #read -p " Please specify src directory [$default]: " SRC if test x$SRC = x; then SRC=$default fi echo "Shared directory /home/dumux set to $SRC" echo "Creating docker container" docker rm $version-container docker create -ti -e USER=$USER -e HOST_GID=$(id -g $USER) -e HOST_UID=$(id -u $USER) -e SRC=$SRC -v $SRC:/home/dumux --name=$version-container --hostname=docker impmx/lswf:$version #mkdir "$SRC/output" exec docker start -a -i $version-container This opens the docker container with the same user as the invoker with read/write privileges in the current and shared directory. If you open the container without the enironment defined in the script, the user will be root and no shared directories. Dune and dumux are installed in /opt and the path and compile flags are ser accordingly. This is to keep user problems separate from dune/dumux core, as is customary for distributed software. User does not have write permissions in opt, but since the include path can be defined by the user, local user versions of model.hh or components or fluidsystems can be redefined on a problem by problem basis. One of the goals of having this docker container is to have more dumux users in our workgroup where these users do not have to fret with the issue of downloading, compiling and installing, which does require a certain level of sophistication which has nothing to do with solving a PDE system. Thus if you run this docker image.and provide any comments or feedback, it will be greatly appreciated. Otherwise, if you find it useful, that makes us happy too. This container still does not have graphic support enabled yet, but that is coming soon. In case you missed it, the image is at the docker hub, repository impmx/lswf with tag dumux-2.12c. The docker file is very much similar to the previous post, but if you want to see the differences, just let me know. Best regards, Edscott 2018-01-11 17:05 GMT-06:00 Ed Scott Wilson Garcia <edsc...@imp.mx>: > Hi Timo, > > > > The Dockerfile at (https://git.iws.uni-stuttgart.de/dumux- > repositories/dumux-docker) is not available for the general public, 404 > error (file not found or insufficient permissions). > > > > But I’ve now build a new Dumux docker image with a dockerfile, which is > much more efficient than what I was doing previously. I’m attaching the > dockerfile if you want to use it for the DockerHub group for DuMux. The > docker image dumux-2.12 built thus at https://hub.docker.com/r/ > impmx/lswf/tags/ > > Has the following characteristics: > > > Built with base/archlinux (jan-11-18) Dune-2.5 and Dumux-2.12.0. > compiled with gcc-7.2.1, cmake-3.10.1, > Dune release/2.5 modules: dune-common, dune-geometry, dune-uggrid, > dune-grid, dune-istl, dune-localfunctions, dune-spgrid, dune-alugrid (head). > With openmpi-3.0.0, superLU, UMFpack, SuiteSparse and many other optional > packages. > > > > Next I will see how to enable graphics support by studying the information > you mention in your post. > > > > Best regards, > > > > Edscott > > > > > > > > *De:* Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] *En nombre > de *Timo Koch > *Enviado el:* miércoles, 3 de enero de 2018 10:47 a. m. > *Para:* DuMuX User Forum; Edscott Wilson > *Asunto:* [DuMuX] DuMux and Docker > > > > Hi Edscott, > > > > I'm writing you as a follow-up on your post on the DUNE mailing list. > > You mention that you use DuMux with Docker. I just wanted to mention a > couple of things you might find useful: > > * There is a Dockerfile (https://git.iws.uni-stuttgart.de/dumux- > repositories/dumux-docker) available to build a docker container with > graphic support. I must warn though that it is a bit old. I will update as > soon as I get to it. > > * There is a script (https://git.iws.uni-stuttgart.de/dumux- > repositories/dumux/blob/master/bin/moduleutil/createdockerimage.sh) that > creates a Docker container of an extracted DUNE module which is new in the > dumux-pub project (https://git.iws.uni-stuttgart.de/dumux-pub). The > Docker container built in this script also fixes the user permissions for > transferring files in and out of containers and has graphic support
gtk+-3.20 DnD x11 issues
Hi all, A good deal of changes went into gdkdnd-x11.c from gtk+-3.18 to gtk+-3.20. And now my application which works fine with gtk+-3.18 crashes when a dnd operation starts. I tried to enable deprecated code which works fine when building with gtk+-2.24, but it crashes just the same. I've spent quite a while trying to figure out what the problem is, whether is is a bug in gtk+-3.20 or whatever. Has anyone else had issues with DnD with gtk+-3.20? If so, how did you solve the issue? TIA -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: argv revisited
2016-05-08 13:41 GMT-05:00 tito-wolit <tito-wo...@tiscali.it>: > If you don't like the advice being given by the experts on this list > why you are still hanging around here? > > Because he's a troll who gets a dopamine hit when someone answers. But I must admit that he is polite and entertaining --although a bit childish--- and brought out good responses from those who have offered help. Many thanks to all those who have responded. With all the advice I'm now going to try cross compiling 64 bit GTK application for windows using all the tools available in ArchLinux and the AUR (which is quite a lot). Only if that fails I'll go back to Msys-Mingw64. -- -------- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GNU libdbh-5.0.17 released.
GNU Libdbh is a small library to create and manage 64-bit disk based hash tables. Libdbh is quite similar to GNU gdbm, but is intended for increased performance when the number of records in your database is in the millions range or above. To see how libdbh performs against gdbm, see section performance at http://www.gnu.org/software/libdbh/ Download available at GNU site: http://download.savannah.gnu.org/releases/libdbh/ And at legacy site: https://sf.net/projects/dbh/files/ Enjoy! Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute -- If you have a working or partly working program that you'd like to offer to the GNU project as a GNU package, see https://www.gnu.org/help/evaluation.html.
[Savannah-register-public] [task #13179] Submission of GNU libdbh
for the home page of the program. Please don't set up a site for the program anywhere else--if you want to do work on additional web pages about the program, please put them on www.gnu.org. (It is ok to put pages that address developers-only topics on another site, and likewise for pages that access databases.) In writing the web pages, please follow the style guidelines in http://www.gnu.org/server/fsf-html-style-sheet.html. See also http://www.gnu.org/prep/maintain/html_node/Web-Pages.html. We ask that you register your package on Savannah, at least to maintain your package's web pages. This is independent of where the actual program sources are hosted (although we encourage you to use Savannah for that too). This makes it easy to update the web pages, since you will have access to a CVS repository for the web pages and can update it as you like. Using Savannah will help the GNU Project in other ways, too. To set this up, visit http://savannah.gnu.org/. If your package was already being developed on Savannah as nongnu, email savannah-help-pub...@gnu.org and ask them to mark it there as a GNU package. This should happen without your intervention, but feel free to ask them if a day or two has gone by without the change being made. Please also write an entry or a change for the page http://www.gnu.org/people/people.html, and mail that to webmast...@gnu.org. Note that we don't want to talk about proprietary software, so if you have worked on any, please don't mention it here. Your entry can include a link to your home page provided it fits our usual criteria for what we link to. Plesae create an entry for your program in directory.fsf.org. It will then be reviewed by (one of) the directory admin(s). Please update the package's entry when they release software updates. See http://www.gnu.org/help/directory.html#adding-entries for help. Mailing lists: please see http://www.gnu.org/prep/maintain/html_node/Mail.html for the details of creating mailing lists. Every GNU package should have at least one, bug-progn...@gnu.org, for reporting bugs. Some GNU programs with many users have another mailing list, help-progn...@gnu.org, for people to ask other users for help. If your program has many users, you should create such a list for it. For a fairly new program, which doesn't have a large user base yet, it is better not to bother with this. Please mail an announcement to info-...@gnu.org about the existence of the program, either when the program is released, or now if the program is already released. Include a brief description of the program so people can tell whether they are interested in using it. The announcement should mention the web pages on www.gnu.org and say where to get releases, normally ftp.gnu.org. Once your program is released, you should make announcements of new releases. Please send them to info-...@gnu.org; you can also send them to a special list info-progn...@gnu.org for your program if you think that is warranted. (These lists should be moderated.) Please also mention release announcements in the news feed of the savannah project site, http://savannah.gnu.org/projects/PROGNAME. The news feeds from the GNU project are aggregated at http://planet.gnu.org/. For more details about writing and publicizing announcements, please see http://www.gnu.org/prep/maintain/html_node/Announcements.html. For details on all policies and recommendations for GNU packages, please see the GNU maintainers information, at http://www.gnu.org/prep/maintain/, and GNU coding standards, at http://www.gnu.org/prep/standards/. new-gnu people, could you please enter Edscott Wilson in gnuorg/maintainers and add him to the gnu-prog lists? Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. Tarball URL: https://sourceforge.net/projects/dbh/files/dbh/ ___ Reply to this item at: http://savannah.gnu.org/task/?13179 ___ Message sent via/by Savannah http://savannah.gnu.org/
[savannah-help-public] boiler plate html template is currently unavailable
http://web.cvs.savannah.gnu.org/viewvc/*checkout*/www/server/standards/boilerplate.html?root=wwwcontent-type=text%2Fplain Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, savannah-hackers@gnu.org and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache/2.2.16 (Debian) Server at web.cvs.savannah.gnu.org Port 80 -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute
Re: [Mingw-w64-public] mingw-w64 and gcc plugins
I guess I misunderstood. I have used plugins in *applications* developed with gcc in mingw-w64. I really haven't looked into plugins used directly by gcc. Of that I am ignorant. sorry. 2014/1/16 xunxun xunxun1...@gmail.com 于 2014/1/17 星期五 6:45, Edscott Wilson 写道: I've used plugins fairly recently. No problem porting from Linux to Windows. Just compile the plugin as a dll and make sure you avoid C++ name mangling. You mean now we can build mingw(64) gcc with --enable-plugin smoothly? -- Best Regards, xunxun -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 and gcc plugins
I've used plugins fairly recently. No problem porting from Linux to Windows. Just compile the plugin as a dll and make sure you avoid C++ name mangling. 2014/1/16 xunxun xunxun1...@gmail.com 于 2014/1/16 星期四 22:13, Иван Иванов 写道: Hello! Is it possible to develop and use GCC plugins with MinGW-w64 on windows? Are there any MinGW-w64 binaries available that supports GCC plugins? I tried googling for it, but couldn't find any. Long long time ago, I ported DragonEgg plugin to Windows: https://code.google.com/p/pcxllvm/downloads/detail?name=Dragonegg_MinGW64CRT_gcc4.6.1_win32.7zcan=1q=#makechanges To build GCC plugin, you will need a special binutils ( can export all symbols ), you can use a my special one: https://code.google.com/p/pcxprj/downloads/detail?name=MinGW_GCC4.6.1_enable_plugin_experimental.7zcan=2q=#makechanges Because of long time, I have forgotten some details, you can refer to these links: http://mingw.5.n7.nabble.com/gcc-enable-plugin-experimental-built-on-windows-td14088.html http://mingw.5.n7.nabble.com/DragonEgg-3-0-for-win32-td5502.html -- Best Regards, xunxun -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Linux/BSD compatible semaphore code
Attached you will find code to make semaphores (as defined in semaphore.h work in a way that is compatible with Linux/FreeBSD. This code includes both named and unnamed semaphores and a working sem_getvalue function (read Linux man page before using sem_getvalue()). To use the code, do not include semaphore.h in your code, instead sem.h. I have prepared it so that with a small patch it can replace the semaphore code in libwinpthread-1.dll, but don't do this just yet. The code in barrier.c should be fixed first. The size of sem_t must be available to programs which include semaphore.h since sem_init() should *not* malloc(). If there is any interest in switching semaphore code to a compatible usage with Linux/BSD I could work up a patch for barrier.c. Example usage for semaphores can be found at https://sourceforge.net/p/xffm/tubo/ci/master/tree/ and will be included in release 5.0.13. sem.h: https://sourceforge.net/p/xffm/tubo/ci/master/tree/src/sem.h sem.c: https://sourceforge.net/p/xffm/tubo/ci/master/tree/src/sem.c In order to debug concurrent threads, trace and error printing is available with a couple macros defined in this file: debug.h: https://sourceforge.net/p/xffm/tubo/ci/master/tree/debug.h Enjoy. -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] (no subject)
Looking at the differences between the patch I submitted for sem.c and
the original code, I figured out why the original code for unnamed
semaphores was crashing my otherwise posix correct use of semaphores.
The sem_init() function is returning the address of a new semaphore,
but this is not right. sem_init() initializes the semaphore *at* the
address pointed. To return the address of a new semaphore, sem_open()
is used.
Furthermore, from the man pages:
Before being used, an unnamed semaphore must be initialized using
sem_init(3). It can then be operated on using
sem_post(3) and sem_wait(3).
When the semaphore is no longer required, and before
the memory in which it
is located is deallocated, the semaphore should
be destroyed using
sem_destroy(3).
So in doubt, I go to the code in glibc, and find:
int
__new_sem_init (sem, pshared, value)
sem_t *sem;
int pshared;
unsigned int value;
{
/* Parameter sanity check. */
if (__builtin_expect (value SEM_VALUE_MAX, 0))
{
__set_errno (EINVAL);
return -1;
}
/* Map to the internal type. */
struct new_sem *isem = (struct new_sem *) sem;
/* Use the values the user provided. */
isem-value = value;
#ifdef __ASSUME_PRIVATE_FUTEX
isem-private = pshared ? 0 : FUTEX_PRIVATE_FLAG;
#else
isem-private = pshared ? 0 : THREAD_GETMEM (THREAD_SELF,
header.private_futex);
#endif
isem-nwaiters = 0;
return 0;
}
Which means that the original code for semaphores in mingw-w64 is not
only incomplete (missing named semaphores) but broken.
The patch I submitted is missing a working sem_getvalue() function.
I'll prepare another patch with that function in working order and
some more changes on off-list suggestions by dw.
--
Dr. Edscott Wilson Garcia
Applied Mathematics and Computing
Mexican Petroleum Institute
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] semaphore wrappers patch
===
--- mingw-w64-libraries/winpthreads/src/sem.h(revision 6379)
+++ mingw-w64-libraries/winpthreads/src/sem.h(working copy)
@@ -1,5 +1,5 @@
/*
- Copyright (c) 2011 mingw-w64 project
+ Copyright (c) 2013 mingw-w64 project
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the
Software),
@@ -22,20 +22,55 @@
#ifndef WIN_SEM
#define WIN_SEM
+# define _WIN32_WINNT 0x502
-#include windows.h
-#include mutex.h
+# include windows.h
+# include sys/stat.h
+# include sys/time.h
+# include stdio.h
+# include errno.h
+# include semaphore.h
-#define LIFE_SEM 0xBAB1F00D
-#define DEAD_SEM 0xDEADBEEF
+#ifdef __cplusplus
+extern C {
+#endif
-typedef struct _sem_t _sem_t;
-struct _sem_t
-{
-unsigned int valid;
-HANDLE s;
-volatile long value;
-pthread_mutex_t vlock;
+#ifndef SEM_FAILED
+#define SEM_FAILED NULL
+#endif
+#ifndef SEM_VALUE_MAX
+#define SEM_VALUE_MAX INT_MAX
+#endif
+
+#ifndef ETIMEDOUT
+#define ETIMEDOUT 138
+#endif
+
+#ifndef _TIMESPEC_DEFINED
+#define _TIMESPEC_DEFINED
+struct timespec {
+ time_t tv_sec; /* Seconds */
+ longtv_nsec; /* Nanoseconds */
};
-#endif /* WIN_SEM */
\ No newline at end of file
+struct itimerspec {
+ struct timespec it_interval; /* Timer period */
+ struct timespec it_value; /* Timer expiration */
+};
+#endif
+
+typedef struct _sem_t {
+ HANDLE handle;
+ BOOL named;
+} _sem_t;
+
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* WIN_SEM */
+
+
+
+
--
Dr. Edscott Wilson Garcia
Applied Mathematics and Computing
Mexican Petroleum Institute
--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] semaphore wrappers
If there is any interest in including the code in ming-w64, I would have no problem in changing the license to that which is used by mingw-w64. Otherwise, anybody who wants to use the code is free to use it under GPL, which is what I use as a matter of habit. 2013/11/14 LRN lrn1...@gmail.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14.11.2013 2:27, Edscott Wilson wrote: Here's the code for using named and unnamed semaphores in Mingw-w64. The only function I have not tested (but looks OK now) is _sem_timedwait(). Code is included in libtubo release 5.0.12 (http://xffm.org/libtubo.html) with GPLV3, so if it is of any use, feel free to use it. I've prepared Mingw-w64 7z package at download site too. // Copyright 2000-2013(C) Edscott Wilson Garcia under GNU GPLv3 AFAIK, mingw-w64 licenses are far more lax than GPLv3, so i doubt that this can be included in winpthreads (in case you thought that this is what would happen). - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJShKEXAAoJEOs4Jb6SI2CwMrwIALCp4a4XssRDXExic+gkAGDX EW96P7lzvVcFhr5/uJxzUBM7WiuJgNDyCn86tQQ9tTWuqQigUuE4GLFVzYI37bJA +3JmpHY0yjmUWBYZwnLN+jS+a/dLLzrJDOSApS6qz23m8/aB0QZcaSxc0GNHe7m2 Vc5+o65BkBWruZfRaAmJsL6g/bw8nvkckdlS/D4oojdmTJP3NQWoqPt9CxJ0NjFR YAMsIQVGSFf5ZQy2rUaaFuOI6II5rBSgMmRV+U8IrHs30XioZDB7nJkleCoEyw9C pyn9bgTKr8LUmLVP/xNWZVXrmpW5NgHMytxdPAQr5R/tSsl7ALX9rhG22MU0dJ0= =LPOD -END PGP SIGNATURE- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] semaphore wrappers
2013/11/14 dw limegreenso...@yahoo.com My mistake, winpthreads itself is BSD, so is it OK to license it as BSD for mingw-w64? If we are going to look at adopting this code, there are few things in it that should be reviewed first. I saw a few when it was first posted, but dropped them when I saw there were licensing issues. I'll look again if we are serious about using it. I did correct the issues you mentioned when you first reviewed the code. I believe _sem_timedwait() is now consistent with what the man page says. Also, as I mentioned before, I have no objection to change the license (in this case to BSD) if it is to be included in mingw-w64. -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] semaphore wrappers
Here's the code for using named and unnamed semaphores in Mingw-w64. The
only function I have not tested (but looks OK now) is _sem_timedwait().
Code is included in libtubo release 5.0.12 (http://xffm.org/libtubo.html)
with GPLV3, so if it is of any use, feel free to use it. I've prepared
Mingw-w64 7z package at download site too.
// Copyright 2000-2013(C) Edscott Wilson Garcia under GNU GPLv3
#ifdef DEBUG_TRACE
# define TRACE(...) \
{ \
fprintf(stderr, TRACE:);\
fprintf(stderr, __VA_ARGS__); \
fflush(stderr);\
}
#else
# define TRACE(...) { (void)0; }
#endif
// Semaphore wrappers
#ifdef HAVE_WINDOWS_H
#include stdarg.h
#include sys/types.h
# define _sem_t HANDLE
#ifndef SEM_FAILED
#define SEM_FAILED ((_sem_t *)(-1))
#endif
#ifndef SEM_VALUE_MAX
#define SEM_VALUE_MAX 1024
#endif
static
_sem_t *_sem_open(const char *name, int oflag, ...){
va_list var_args;
int mode;
unsigned int value;
TRACE(-- _sem_open(%s)\n, name);
_sem_t *sem = (_sem_t *)malloc(sizeof(_sem_t));
if (!sem) {
fprintf(stderr, *** Tubo: malloc(%d): %s\n,
sizeof(_sem_t),strerror(errno));
return (_sem_t *)SEM_FAILED;
}
HANDLE handle;
if (oflag O_CREAT) {
va_start(var_args, oflag);
mode = va_arg(var_args, int);
value = va_arg(var_args, unsigned int);
va_end(var_args);
handle = CreateSemaphore(NULL, (LONG) value, (LONG) SEM_VALUE_MAX,
name);
} else {
handle = OpenSemaphore( SEMAPHORE_ALL_ACCESS, FALSE, name);
}
if (handle == NULL){
TRACE(-- %s semaphore %s failed.\n, (oflag
O_CREAT)?Create:Open, name);
errno = EINVAL;
free(sem);
return (_sem_t *)SEM_FAILED;
}
TRACE (-- %s semaphore %s (%d) OK!\n, (oflag
O_CREAT)?Create:Open, name,
(intptr_t)handle);
*sem = handle;
return sem;
}
static
int _sem_init(_sem_t *sem, int pshared, unsigned int value){
HANDLE handle = CreateSemaphore(NULL, (LONG) value, (LONG)
SEM_VALUE_MAX, NULL);
if (handle == NULL) {
fprintf(stderr, *** Tubo: Error in CreateSemaphore: %d\n,
GetLastError());
return -1;
}
TRACE(-- _sem_open(unnamed) got %d initialized to %d\n,
(intptr_t)handle, value);
SetHandleInformation(handle, HANDLE_FLAG_PROTECT_FROM_CLOSE,
HANDLE_FLAG_PROTECT_FROM_CLOSE);
*sem = handle;
return 0;
}
static
int _sem_close(_sem_t *sem){
TRACE(closing semaphore %d\n, *sem);
if (!sem || sem == SEM_FAILED) {
errno = EBADF;
return -1;
}
DWORD dwFlags;
GetHandleInformation(*sem, dwFlags);
int unnamed = 0;
if (dwFlags HANDLE_FLAG_PROTECT_FROM_CLOSE) {
unnamed = 1;
SetHandleInformation(*sem, HANDLE_FLAG_PROTECT_FROM_CLOSE, 0);
}
BOOL result = CloseHandle(*sem);
if (!result){
errno = EINVAL;
return -1;
}
// If it is a named semaphore, we must free allocated memory.
if (!unnamed) {
TRACE(Free sem %d now\n, *sem);
free(sem);
} else TRACE(Will not free sem %d (unnamed)\n, *sem);
return 0;
}
static
int _sem_unlink(const char *name){
// Big Fat Warning:
// Windows does this when all processes close the semaphore.
return 0;
}
static
int _sem_post(_sem_t *sem){
TRACE(Releasing semaphore %d\n, *sem);
BOOL result = ReleaseSemaphore( *sem, 1, NULL);
if (!result) return -1;
return 0;
}
static
int _sem_timeout(_sem_t *sem, long timeout){
TRACE(Wait on semaphore %d\n, *sem);
DWORD result = WaitForSingleObject(*sem, timeout);
switch (result){
case WAIT_OBJECT_0:
TRACE(Wait OK on semaphore %d\n, *sem);
return 0;
case WAIT_TIMEOUT:
TRACE(Wait timed out on semaphore %d\n, *sem);
return -1;
case WAIT_FAILED:
TRACE(Wait failed on semaphore %d\n, *sem);
return -1;
}
}
static
int _sem_timedwait(_sem_t *sem, const struct timespec *abs_timeout){
struct timeval tv;
if (gettimeofday(tv, NULL) 0) return -1;
time_t seconds = abs_timeout-tv_sec - tv.tv_sec;
long milliseconds = seconds * 1000;
long microseconds = (abs_timeout-tv_nsec / 1000) - tv.tv_usec;
milliseconds += (microseconds/1000);
return tubo_sem_timeout(sem, milliseconds);
}
#define _sem_wait(X) _sem_timeout(X, INFINITE)
#define _sem_trywait(X) _sem_timeout(X, 0L)
#else
# define _sem_t sem_t
# define _sem_open(...) sem_open(__VA_ARGS__)
# define _sem_close(X) sem_close(X)
# define _sem_unlink(X) sem_unlink(X)
# define _sem_post(X) sem_post(X)
# define _sem_wait(X) sem_wait(X)
# define _sem_init(X,Y,Z) sem_init(X,Y,Z)
# define _sem_trywait(X) sem_trywait(X)
# define _sem_timedwait(X) sem_timedwait(X)
#endif
2013/11/11 Edscott Wilson edscott.wilson.gar...@gmail.com
2013/11/9 dw limegreenso...@yahoo.com
handle = CreateSemaphore(NULL, (LONG) value, (LONG) 1024, name);
Why 1024
Re: [Mingw-w64-public] semaphore wrappers
2013/11/9 dw limegreenso...@yahoo.com
handle = CreateSemaphore(NULL, (LONG) value, (LONG) 1024, name);
Why 1024? Is this the same as SEM_VALUE_MAX?
Probably not the same. I'm now changing it to SEM_VALUE_MAX.
if (handle == NULL){
LPTSTR buffer;
errno = EINVAL;
return (_sem_t *)SEM_FAILED;
}
What's the buffer for?
Missed that on cleanup. It was there for debugging purposes but now is
useless.
static int _sem_timedwait(_sem_t *sem, const struct timespec
*abs_timeout){
long milliseconds = abs_timeout-tv_sec * 1000;
milliseconds += (abs_timeout-tv_nsec/100);
tubo_sem_timeout(sem, milliseconds);
}
This doesn't appear to match the man
pagehttp://man7.org/linux/man-pages/man3/sem_wait.3.htmlI read: If the
timeout has already expired by the time of the call
implies that an absolute time is being specified, not a duration. While I
think your definition is more useful, this may result in unexpected
behavior for others.
Right. An absolute time is better to keep things consistent. As soon as I
put in the code to support unnamed semaphores, I'll post the corrected code
to the list.
Thanks for your comments!
Dr. Edscott Wilson Garcia
Applied Mathematics and Computing
Mexican Petroleum Institute
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: rules on generating dlname
Well, figured it out. I had this in configure.ac: m4_define([release], [1]) This breaks the definition of dlname in the .la file libtool produces. 2013/11/3 Edscott Wilson edscott.wilson.gar...@gmail.com I've read through the libtool manual and google'd around, but the following has me dumfounded. When I compile the librfm library (basic functions for Rodent Filemanager, http://xffm.org), I get the following stuff in .libs: -- lrwxrwxrwx 1 edscott users 16 nov 3 00:18 librfm1.so.1 - librfm1.so.1.0.1 -rwxr-xr-x 1 edscott users 261997 nov 3 00:18 librfm1.so.1.0.1 lrwxrwxrwx 1 edscott users 12 nov 3 00:18 librfm.la - ../librfm.la -rw-r--r-- 1 edscott users952 nov 3 00:18 librfm.lai lrwxrwxrwx 1 edscott users 16 nov 3 00:18 librfm.so - librfm1.so.1.0.1 But the librfm.la file specifies a weird name: # The name that we can dlopen(3). dlname='librfmlibrfm1.so.1.so.1' This symlink gets generated when I do a make install. Why does libtool use this weird name? I guess it means something, but I can't figure it out. Other libraries I create with libtool have regular a dlname (one of the library_names). Could anyone please tell me what libtool means when this kind of weird dlname is generated in the .la file? Any pointer would be greatly appreciated. Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute ___ https://lists.gnu.org/mailman/listinfo/libtool
[Mingw-w64-public] semaphore wrappers
Here's some code to enable named semaphores as defined in semaphore.h.
I've tested it with the libtubo example program and all
seems to work well. The only caveat is that windows will unlink the
semaphore when the last process closes the semaphore. This goes hand in
hand with the inability of windows to unlink a file whilst a process has an
open file descriptor on the file. So you have to be careful not to do the
close on the semaphore before the remote process has a chance to open it.
Support for unnamed semaphore is not yet in the code.
// Semaphore wrappers
#ifdef HAVE_WINDOWS_H
#include stdarg.h
#include sys/types.h
# define _sem_t int
static
_sem_t *_sem_open(const char *name, int oflag, ...){
va_list var_args;
int mode;
unsigned int value;
HANDLE handle;
if (oflag O_CREAT) {
va_start(var_args, oflag);
mode = va_arg(var_args, int);
value = va_arg(var_args, unsigned int);
va_end(var_args);
handle = CreateSemaphore(NULL, (LONG) value, (LONG) 1024, name);
} else {
handle = OpenSemaphore( SEMAPHORE_ALL_ACCESS, FALSE, name);
}
if (handle == NULL){
LPTSTR buffer;
errno = EINVAL;
return (_sem_t *)SEM_FAILED;
}
return (_sem_t *)handle;
}
static int _sem_close(_sem_t *sem){
if (!sem || sem == SEM_FAILED) {
errno = EBADF;
return -1;
}
BOOL result = CloseHandle(sem);
if (!result){
errno = EINVAL;
return -1;
}
return 0;
}
static int _sem_unlink(const char *name){
// Windows does this when all processes close the semaphore.
return 0;
}
static int _sem_post(_sem_t *sem){
BOOL result = ReleaseSemaphore( sem, 1, NULL);
if (!result) return -1;
return 0;
}
static int _sem_timeout(_sem_t *sem, long timeout){
DWORD result = WaitForSingleObject(sem, timeout);
switch (result){
case WAIT_OBJECT_0:
return 0;
case WAIT_TIMEOUT:
return -1;
case WAIT_FAILED:
return -1;
}
}
static int _sem_timedwait(_sem_t *sem, const struct timespec *abs_timeout){
long milliseconds = abs_timeout-tv_sec * 1000;
milliseconds += (abs_timeout-tv_nsec/100);
tubo_sem_timeout(sem, milliseconds);
}
#define _sem_wait(X) _sem_timeout(X, INFINITE)
#define _sem_trywait(X) _sem_timeout(X, 0L)
#else
# define _sem_t sem_t
# define _sem_open(...) sem_open(__VA_ARGS__)
# define _sem_close(X) sem_close(X)
# define _sem_unlink(X) sem_unlink(X)
# define _sem_post(X) sem_post(X)
# define _sem_wait(X) sem_wait(X)
# define _sem_trywait(X) sem_trywait(X)
# define _sem_timedwait(X) sem_timedwait(X)
#endif
--
Dr. Edscott Wilson Garcia
Applied Mathematics and Computing
Mexican Petroleum Institute
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Shared semaphores
No need to be sorry. Great stuff, this MinGW-w64.
As soon as I cook up some wrapper code and test it in libtubo, I'll post it
for your review.
2013/11/7 LRN lrn1...@gmail.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07.11.2013 22:34, LRN wrote:
On 07.11.2013 22:00, Edscott Wilson wrote:
Ok. So I now I ran more tests. To start with, I replaced the
unnamed process-shared semaphore for a more compatible named
semaphore, which by definition is process-shared. The code works
fine in Linux and FreeBSD. But in MinGW-w64, no such luck.
I tried the toolchain in *mingw-w64-v3.0.0.tar.bz2,
https://sourceforge.net/projects/mingw-w64/files/latest/download?source=files
*
and the one in x86_64-4.8.2-release-posix-seh-rt_v3-rev0.7z and the
one in
x86_64-4.8.2-release-win32-seh-rt_v3-rev0.7z, all with the same
results on the following code:
sem_t *sem = sem_open(sem_name, O_CREAT|O_EXCL, 0700, 0); if
(sem == SEM_FAILED) { fprintf(stderr, ***Cannot create named
semaphore: %s(%s)\n, sem_name, strerror(errno)); return 0; }
Which produces:
***Cannot create named semaphore: \Tubo-1300-1-stdout (Function
not implemented)
So my guess is that unnamed semaphores are not implemented
either, because when I try to use them, I invariably get a crash
(instead of the graceful exit shown above).
This is the implementation of sem_open in winpthreads:
sem_t * sem_open (const char *name, int oflag, mode_t mode,
unsigned int value) { sem_result (ENOSYS); return NULL; }
So no one even attempted to implement semaphore opening in any way
(not just shared semaphore opening). It doesn't mean it's
impossible though.
Now that i've read the sem_init() source code in winpthreads
carefully, i see that sem_init fails with EPERM if pshared is not
PTHREAD_PROCESS_PRIVATE (which is defined as 0).
Which means that shared semaphores support was not implemented even at
initialization part.
Sorry.
- --
O ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJSe95MAAoJEOs4Jb6SI2CwV6cH/jwqrdnbfypvKEaIFzBijifQ
qiu694u/LCoUcxOK9ih5LBp/LwK9ydBSAZqcMPz7lkYTYdVb/ZEkucPxkUa1kWA0
/Ed+u8lUwjo3/HstmWcIbU6CVCN3r5ebj7R0bkZaH13ioC+A37aUYPQHb5kVzBeD
1Gs/X0F2OLrvLpdFCsYhCttQVTg0mOv/wKd7lLzA7XbpiD6AxfDOJjoSo5iTDF5u
qyGK8YkF6VnYMjwcS2UIYYwmLEDXhW7bEO3E1h3nZMNFc7tC4AWWKQEp6iq280MO
g+u9goRF0WlENBUSox/8apRlRd1mwWrjxFELpJ96Q1tiRLzmB5ZHoREIVYEkJ4E=
=lnfb
-END PGP SIGNATURE-
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models.
Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and
register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Dr. Edscott Wilson Garcia
Applied Mathematics and Computing
Mexican Petroleum Institute
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Shared semaphores
: --- This GDB was configured as i686-pc-mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from d:\git\tubo\src\.libs\example.exe...done. (gdb) run Starting program: d:\git\tubo\src\.libs\example.exe [New Thread 6504.0x17f8] command (exit to end):ls found: E:\MinGW\msys\1.0\bin\ls.exe exec Main process id = 0x1968 posting semaphore 1... posted semaphore 1 ! Child process id= 0x1080 Controller process id= 0x1980 Tubo_id() = 0x2 wait is done for 0x1080 0x1968: Tubo_exec thread processing: Makefile 0x1968: Tubo_exec thread processing: Makefile.am 0x1968: Tubo_exec thread processing: Makefile.in 0x1968: Tubo_exec thread processing: example-example.o 0x1968: Tubo_exec thread processing: example-tubo.o 0x1968: Tubo_exec thread processing: example-tubo_exec.o 0x1968: Tubo_exec thread processing: example.c 0x1968: Tubo_exec thread processing: example.exe 0x1968: Tubo_exec thread processing: libtubo.dll 0x1968: Tubo_exec thread processing: libtubo.la 0x1968: Tubo_exec thread processing: libtubo_la-tubo.lo 0x1968: Tubo_exec thread processing: libtubo_la-tubo.o 0x1968: Tubo_exec thread processing: libtubo_la-tubo_exec.lo 0x1968: Tubo_exec thread processing: libtubo_la-tubo_exec.o 0x1968: Tubo_exec thread processing: tubo.c 0x1968: Tubo_exec thread processing: tubo.h 0x1968: Tubo_exec thread processing: tubo_exec.c 0x1968: Tubo_exec thread processing: tubo_exec.c~ 0x1968: Tubo_exec thread processing: tubo_exec.i 0x1968: Tubo_exec thread processing: tubo_exec.i~ 0x1968: Tubo_exec thread processing: tubo_main.c 0x1968: Tubo_exec thread processing: tubo_static.i 0x1968: Tubo_exec thread processing: tuboexec-tubo.o 0x1968: Tubo_exec thread processing: tuboexec-tubo_main.o 0x1968: Tubo_exec thread processing: tuboexec.exe 0x1968: Tubo_exec thread processing: [New Thread 6504.0x1798] [New Thread 6504.0x1be4] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 6504.0x1798] 0x62487810 in pthread_mutex_lock () from e:\MinGW\bin\pthreadGC2.dll --- That's the extent of information I could get from gdb, but after fiddling around, I find that a sem_ command (probably sem_wait) is causing the crash with the detected pthread_mutex_lock() call. So me figures that pthread semaphores are just constructed with pthread_conditions. So instead I use mutex/condition to hack up a control equivalent to the required semaphore and everything works just fine. That leads me to believe that there may be some race condition with semaphores in pthreadGC2, where the associated mutex of the underlying control structure gets freed before its time is really up. This is what I was talking about. All this was done with plain MingW. I have yet to build dll's with Mingw-64, but I surmise the issue will be the same. I'll be glad to provide any more information if needed. HTH -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Shared semaphores
2013/11/5 Ruben Van Boxem vanboxem.ru...@gmail.com If you have pthreadGC2.dll, you are not using winpthreads, but pthreads-win32, an older and completely different project. What toolchain are you using? I don't think you're using MinGW-w64, but the older and less complete MinGW(.org). You can get MinGW-w64 from here: http://sourceforge.net/projects/mingwbuilds/files/mingw-builds-install/mingw-builds-install.exe Or seperate downloads via here: http://mingw-w64.sourceforge.net/download.php#mingw-builds Initially I was using MinGW(.org), supposing the problem would be inherited. So now I have tested on MinGW-w64. The crash happens just the same (see below), except that gdb figures it out at libwinpthread-1.dll. I'll try to look into the problem a little bit more tomorrow. Maybe test with named semaphores and see how the cookie crumbles. gcc --version gcc.exe (rev5, Built by MinGW-W64 project) 4.8.1 This GDB was configured as x86_64-w64-mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from d:\GIT\tubo\src\.libs\example.exe...done. (gdb) run Starting program: d:\GIT\tubo\src\.libs\example.exe [New Thread 5920.0x404] command (exit to end):ls found: D:\msys\1.0\bin\ls.exe exec Main process id = 0x1720 0x1720: Tubo_exec thread processing: Makefile 0x1720: Tubo_exec thread processing: Makefile.am 0x1720: Tubo_exec thread processing: Makefile.in 0x1720: Tubo_exec thread processing: example-example.o 0x1720: Tubo_exec thread processing: example-tubo.o 0x1720: Tubo_exec thread processing: example-tubo_exec.o 0x1720: Tubo_exec thread processing: example.c 0x1720: Tubo_exec thread processing: example.exe 0x1720: Tubo_exec thread processing: libtubo.dll 0x1720: Tubo_exec thread processing: libtubo.la 0x1720: Tubo_exec thread processing: libtubo_la-tubo.lo 0x1720: Tubo_exec thread processing: libtubo_la-tubo.o 0x1720: Tubo_exec thread processing: libtubo_la-tubo_exec.lo 0x1720: Tubo_exec thread processing: libtubo_la-tubo_exec.o 0x1720: Tubo_exec thread processing: tubo.c 0x1720: Tubo_exec thread processing: tubo.h 0x1720: Tubo_exec thread processing: tubo_exec.c 0x1720: Tubo_exec thread processing: tubo_exec.c~ 0x1720: Tubo_exec thread processing: tubo_exec.i 0x1720: Tubo_exec thread processing: tubo_exec.i~ 0x1720: Tubo_exec thread processing: tubo_main.c 0x1720: Tubo_exec thread processing: tubo_static.i 0x1720: Tubo_exec thread processing: tuboexec-tubo.o 0x1720: Tubo_exec thread processing: tuboexec-tubo_main.o 0x1720: Tubo_exec thread processing: tuboexec.exe 0x1720: Tubo_exec thread processing: command (exit to end):[New Thread 5920.0x1ad0] [New Thread 5920.0x16bc] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 6932.0x1ba0] 0x6494313a in ?? () from d:\mingw64\bin\libwinpthread-1.dll --- -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Shared semaphores
Well I did my testing of semaphores to release a windows version of libtubo (http://xffm.org/libtubo.html) and these are my two cents. 1- Shared semaphores (shared between heavy weight processes). In Linux, a shared semaphore must be placed in shared memory. This is easy, since the shm_ family of functions allow you to map any type of pointer to shared memory. Windows, on the other hand, CreateFileMapping for shared memory gives you a file descriptor which is no good for mapping a POSIX semaphore. In any case, Windows has its own CreateSemaphore function, which most probably uses CreateFileMapping internally. I opted for a different control method instead. 2- Local semaphores (shared only between threads). Posix semaphores in Mingw seem to be subject to race conditions not present in Linux or FreeBSD. When I tried to use them in Windows, libtubo would crash. So I replaced these semaphores with pthread conditions and things worked just fine. 2013/10/21 Edscott Wilson edscott.wilson.gar...@gmail.com 2013/10/21 LRN lrn1...@gmail.com W32 semaphores[1] are shared by default. mingw-w64 winpthreads use these semaphores internally when pshared is PTHREAD_PROCESS_SHARED, so yes, this is supported (judging by the code; you will have to test it to see if it actually works). Will do the testint. I'll let you know what turns up. Thanks. -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Shared semaphores
As I understand it, all it takes to get a POSIX semaphore in windows is to include semaphore.h and link with -lpthread. Windows semaphores are defined in windows.h. Since POSIX semaphores are in libpthread, they would be pthread semaphores. Nonetheless, I think they have a different flavor. The bulk of pthread functionality is namespaced with a pthread_, while semaphore functions are namespaced with sem_. . Pthread_ stuff applies only to threads, created with pthread_create. While semaphores may apply to independent processes. As far as I recall, semaphores require interaction with the kernel, while pthread stuff is contained within the running program. Thus, semaphores are slower. Back in the stone age, semaphores were *not* a part of the pthread library, and each vendor provided his own library. This was before the days when Linux took over the supercomputers and each vendor prepared a proprietary BSD based OS for his hardware. This takes us back to the point where semaphores have to talk to the kernel. The windows kernel, IMHO, is not a trustworthy kernel, so pthread conditions are a better option. HTH 2013/11/4 Kai Tietz ktiet...@googlemail.com Hi Edscott, thanks for testing this. I just have one small question about one paragraph. 2013/11/4 Edscott Wilson edscott.wilson.gar...@gmail.com: 2- Local semaphores (shared only between threads). Posix semaphores in Mingw seem to be subject to race conditions not present in Linux or FreeBSD. When I tried to use them in Windows, libtubo would crash. So I replaced these semaphores with pthread conditions and things worked just fine. What is a Posix semaphore in Windows? And what is its difference to pthread's semaphore? I might confused myself, but this paragraph puzzles me. Thanks for more detailed description. Regards, Kai -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Shared semaphores
2013/11/4 Kai Tietz ktiet...@googlemail.com Pthread_ stuff applies only to threads, created with pthread_create. While semaphores may apply to independent processes. As far as I recall, semaphores require interaction with the kernel, while pthread stuff is contained within the running program. Thus, semaphores are slower. That is not 100% correct. pthread-stuff can be used within none-pthread-created threads, too. Of course those none-pthread threads are treated like detached ones by default. Cool. That is interesting. I must try it out. regards -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
rules on generating dlname
I've read through the libtool manual and google'd around, but the following has me dumfounded. When I compile the librfm library (basic functions for Rodent Filemanager, http://xffm.org), I get the following stuff in .libs: -- lrwxrwxrwx 1 edscott users 16 nov 3 00:18 librfm1.so.1 - librfm1.so.1.0.1 -rwxr-xr-x 1 edscott users 261997 nov 3 00:18 librfm1.so.1.0.1 lrwxrwxrwx 1 edscott users 12 nov 3 00:18 librfm.la - ../librfm.la -rw-r--r-- 1 edscott users952 nov 3 00:18 librfm.lai lrwxrwxrwx 1 edscott users 16 nov 3 00:18 librfm.so - librfm1.so.1.0.1 But the librfm.la file specifies a weird name: # The name that we can dlopen(3). dlname='librfmlibrfm1.so.1.so.1' This symlink gets generated when I do a make install. Why does libtool use this weird name? I guess it means something, but I can't figure it out. Other libraries I create with libtool have regular a dlname (one of the library_names). Could anyone please tell me what libtool means when this kind of weird dlname is generated in the .la file? Any pointer would be greatly appreciated. Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute ___ https://lists.gnu.org/mailman/listinfo/libtool
[Mingw-w64-public] Shared semaphores
In Linux, you can get a piece of shared memory, put a posix semaphore in there, and use it amongst independent processes. This is done by setting the second parameter of sem_init() to 1. In FreeBSD this functionality is not supported (at least the last time I looked). Does anybody on the list know if shared semaphores are supported in Mingw64? -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] DBH project now using ming64
With release 5.0.8, Disk Based HashTables ( http://sourceforge.net/projects/dbh) project is now successfully using Mingw-64. Many thanks to the Mingw-64 developers who have made this possible. -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] SOLVED Short read mystery
I appreciate all the responses. This is the result. 1. The option O_BINARY is not available in fcntl.h for gcc, So open(test.dbh, O_RDWR|O_BINARY) does not work. 2. Neither will the unix2dos program work since the file to open is a binary file which must be read byte by byte. 3. fopen(test.dbh, rb) seems to have nailed it. Since I require use of lseek() later on, I need a file descriptor. So the solution (hack?) that works is the following: FILE *f = fopen(test.dbh, rb); int fd = fileno(f); With that, the read(fd, data, 256) will read the correct amount of bytes. Thanks! -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] SOLVED Short read mystery
2013/10/16 Ruben Van Boxem vanboxem.ru...@gmail.com 2013/10/16 Edscott Wilson edscott.wilson.gar...@gmail.com I appreciate all the responses. This is the result. 1. The option O_BINARY is not available in fcntl.h for gcc, So open(test.dbh, O_RDWR|O_BINARY) does not work. See MSDN for the flags you are looking for: http://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx The problem with that is I want to use mingw-64's gcc, and gcc does not define O_BINARY, and does not seem likely that it will in the future. Maybe the mingw port should include O_BINARY and O_TEXT. Funny thing is that fread() and fwrite() assume a binary stream, even if FILE is not opened with the b flag. ( http://manpages.courier-mta.org/htmlman3/fread.3.html) whileas read() and write() do not make that assumption (http://linux.die.net/man/2/read). That was why the test program could correctly read the binary file with fread() (opened without the b flag), but read() failed miserably. I do not see any reason why read() and write() should not assume binary input/output just as fread() and fwrite() do. -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] SOLVED Short read mystery
You are absolutely right. I took a look into fcntl.h and there it was. Apparently my configure script is defining NO_OLDNAMES and not defining _POSIX. I dunno why. But the _O_BINARY option works just fine and allows me to avoid the hack with fopen/fileno. Thanks a bunch. Now I can go ahead and release http://dbh.sf.net 5.0.8 for windows sometime during the next few days. 2013/10/16 Ozkan Sezer seze...@gmail.com On 10/16/13, Edscott Wilson edscott.wilson.gar...@gmail.com wrote: 2013/10/16 Ruben Van Boxem vanboxem.ru...@gmail.com 2013/10/16 Edscott Wilson edscott.wilson.gar...@gmail.com I appreciate all the responses. This is the result. 1. The option O_BINARY is not available in fcntl.h for gcc, So open(test.dbh, O_RDWR|O_BINARY) does not work. See MSDN for the flags you are looking for: http://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx The problem with that is I want to use mingw-64's gcc, and gcc does not define O_BINARY, and does not seem likely that it will in the future. Maybe the mingw port should include O_BINARY and O_TEXT. gcc itself doesn't define O_BINARY, but fcntl.h from mingw[-w64] projects *do* define it: make sure that you include fcntl.h. If for some weird reason you are defining NO_OLDNAMES or something, then use _O_BINARY with the leading underscore. -- O.S. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] to test for MinGW64
If you use gnu autotools it's really simple. Just put something like this into configure.ac AC_CHECK_HEADERS(windows.h) And then use #ifdef HAVE_WINDOWS_H do this #else do that #endif 2013/10/16 Incongruous incongru...@outlook.com Thanks everyone. *From:* Incongruous incongru...@outlook.com *Sent:* Tuesday, October 15, 2013 6:06 AM *To:* MinGW-64 Mailinglist mingw-w64-public@lists.sourceforge.net *Subject:* [Mingw-w64-public] to test for MinGW64 I would like to test for MinGW64 to include or exclude some code; something like: #ifdef MinGW64 doThis(); #endif #ifdef __MSV__ doSomthingElse #endif is this possible? tia -- -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Short read mystery
I've been banging my head against the monitor for the past nine hours and
narrowed a problem down to the following.
I've found that for certain data, the read() function will return a short
byte count.
Take the following test file: http://xffm.org/test.dbh and compile and
execute the following program:
#include stdio.h
#include stdlib.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include errno.h
int main(int argc, char **argv){
int fd = open(test.dbh,O_RDWR);
void *data = malloc(256);
size_t bytes = read(fd, data, 256);
printf(bytes read=%ld\n, (long)bytes);
printf(errno=%s\n, strerror(errno));
close(fd);
FILE *f = fopen(test.dbh, r);
bytes = fread(data, 1, 256, f);
printf(bytes fread=%ld\n, (long)bytes);
return 1;
}
This is the output of the above program compiled with mingw gcc:
bytes read=255
errno=No error
bytes fread=256
Which is wrong. I get the same broken result with both:
gcc.exe (rev5, Built by MinGW-W64 project) 4.8.1
and
gcc.exe (GCC) 4.6.2 (from mingw-32)
Linux, of course, reads the 256 bytes correctly.
So there is something in the file which breaks the read on Windows.
What could possibly be wrong?
Is there some Windows trick you need apply to make read() work as it is
intended?
Or would it be a bug of the mingw gcc port?
Any help is appreciated.
--
Dr. Edscott Wilson Garcia
Applied Mathematics and Computing
Mexican Petroleum Institute
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: Glib::ustring in mingw
Problem solved, more or less. The issue is with gcc compiler. Apparently the gtkmm bundle package is build with gcc-4.6.2, and some hack or other is done to get glib/glibmm to compile. If you try to compile and link your program with a different gcc version (I tried 4.7.0 and 4.7.2) the ustring constructor in glibmm is broken and will invariably lead to SEGV. Using a mingw with the packaged compiler and tools, there is no problem with Glib:ustring. So the quick fix is to install mingw with the packaged gcc (4.6.2) and use this to build gtkmm packages. Plain gtk+ will most probably work correctly with gcc-4.7.2 or later. 2013/9/9 Alcione Ferreira alcione.som...@gmail.com Only confirmed! Managed to solve your problem? Só confirmando! Conseguiu resolver seu problema? --- 2013/9/3 Edscott Wilson edscott.wilson.gar...@gmail.com Thank you! I will try your suggestion. 2013/9/2 Alcione Ferreira alcione.som...@gmail.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Em 02-09-2013 19:42, Edscott Wilson escreveu: Hey, If I use Glib::ustring in Linux, everything works fine. But when I compile the program under mingw in windows, segv invariably follows any GLib::ustring. Methinks the culprit would be the internal utf-8 conversions which distiguish Glib:ustring from std:string. If I try to specify locale with: |std::locale::global(std::locale());| Will abort the program (invalid locale, windows will argue). The only locale that seems to work is C. Further information: the program in question is also using glade to build the gtk window framework. Maybe the glade gettext stuff screws things up with Glib::ustring? Usage of giomm and other functions which rely on Glib:ustring will also lead to segv. Any ideas or pointers on the subject will be greatly appreciated. Boa noite! Tive problemas com a convers￣o de tipos no in￭cio mas o Glib::ustring resolveu tudo sem problemas, a nica altera￣o que tive que fazer para sistemas em win32 foi acrescentar a biblioteca correspondente ao SO windows.h. Segue o techo que usei para testar: #if defined(__WIN32__) || defined(__WIN__) #include windows.h #endif Para esclarecer tenho um sistema de Fluxo de Caixa rodando em ambos os sistemas feito em GTKmm com acesso a banco de dados MYSQL e POSTGRESQL. Att. Good night! I had problems with type conversion in the beginning but the Glib :: ustring solved everything without problems, the only change I had to do was to add win32 systems in the library corresponding to SO windows.h. Follows the techo I used to test: # if defined (__WIN32__) | | defined (__WIN__) # include windows.h # endif To have a clear system cash flow running on both systems made ??in GTKmm with access to MYSQL database and POSTGRESQL. Att - -- Paz e Bem! Alcione Ferreira Sombraﾮ 101080 [http://www.alcionesytes.net/] - --- Liberdade e conhecimento ao alcance de todos. Office Escritrio - http://www.openoffice.org.br/ Navegador Firefox - http://www.mozilla.org.br/ Email Thunderbird - http://www.mozilla.org.br/ - --- Linux user number 432030 of http://counter.li.org/ - --- ICQ: 377035698 Jabber: ksomb...@jabber.org MSN: alcione.som...@hotmail.com - --- Curriculum: http://lattes.cnpq.br/0545256741852110 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIlWlYACgkQ3m8gMw0vje8rsQCghrsGF7EUgmotLNOaI9m1UpAV e/IAn0Bk7n19EezZWyXRSFPXol0n046D =yiEc -END PGP SIGNATURE- ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- *Paz e Bem!* Alcione Ferreira Sombra® 101080 [http://www.alcionesytes.net/] --- Liberdade e conhecimento ao alcance de todos. Office Escritório - http://www.openoffice.org.br/ Navegador Firefox - http://www.mozilla.org.br/ Email Thunderbird - http://www.mozilla.org.br/ --- Linux user number 432030 of http://counter.li.org/ --- ICQ: 377035698 Jabber: ksomb...@jabber.org MSN: sombra_mes...@hotmail.com --- Curriculum: http://lattes.cnpq.br/0545256741852110 -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing
Glib::ustring in mingw
Hey, If I use Glib::ustring in Linux, everything works fine. But when I compile the program under mingw in windows, segv invariably follows any GLib::ustring. Methinks the culprit would be the internal utf-8 conversions which distiguish Glib:ustring from std:string. If I try to specify locale with: std::locale::global(std::locale()); Will abort the program (invalid locale, windows will argue). The only locale that seems to work is C. Further information: the program in question is also using glade to build the gtk window framework. Maybe the glade gettext stuff screws things up with Glib::ustring? Usage of giomm and other functions which rely on Glib:ustring will also lead to segv. Any ideas or pointers on the subject will be greatly appreciated. -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: [OMPI users] Set number of processes in another way than -np X
gt;>> I'm newbie in the use of MPI, so probably I ask some stupid question >>>> (or previously asked, but in this case I have searched in the archive and I >>>> haven't found anything): >>>> >>>> Exists any other way than -np X in order to pass the number of >>>> processes to start for an MPI program? I mean a function of the style >>>> MPI_Set_Number_Processes() or similar >>>> >>>> Thanks >>>> >>>> -- >>>> * >>>> José Luis García Pallero >>>> jgpall...@gmail.com >>>> (o< >>>> / / \ >>>> V_/_ >>>> Use Debian GNU/Linux and enjoy! >>>> * >>>> ___ >>>> users mailing list >>>> us...@open-mpi.org >>>> http://www.open-mpi.org/mailman/listinfo.cgi/users >>>> >>>> >>>> >>>> ___ >>>> users mailing list >>>> us...@open-mpi.org >>>> http://www.open-mpi.org/mailman/listinfo.cgi/users >>>> >>> >>> >>> >>> -- >>> * >>> José Luis García Pallero >>> jgpall...@gmail.com >>> (o< >>> / / \ >>> V_/_ >>> Use Debian GNU/Linux and enjoy! >>> * >>> ___ >>> users mailing list >>> us...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/users >>> >>> >>> >>> ___ >>> users mailing list >>> us...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/users >>> >> >> >> >> -- >> * >> José Luis García Pallero >> jgpall...@gmail.com >> (o< >> / / \ >> V_/_ >> Use Debian GNU/Linux and enjoy! >> * >> ___ >> users mailing list >> us...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/users >> >> >> >> ___ >> users mailing list >> us...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/users >> > > > > -- > * > José Luis García Pallero > jgpall...@gmail.com > (o< > / / \ > V_/_ > Use Debian GNU/Linux and enjoy! > * > ___ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users > > > ___ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users > > > ___ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users > -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute
Re: GTK+ 3.8.0 released
2013/3/26 Allin Cottrell cottr...@wfu.edu On Tue, 26 Mar 2013, Edscott Wilson wrote: It would be nice know that =pango1.32.4 means that systems with fontconfig, freetype and xft if and only if harfbuzz = 0.9.9. Seems like the pango 1.32.4 configure.ac tests in things in the wrong order. Not sure about that, but the thing that bothers me is that the shiny new pango 1.34.0 (latest stable, one might suppose) depends on a release-candidate version of fontconfig (2.10.91). From the configure script of 1.32.4, the test for fontconfig=2.5.0 will only take place if the condition harfbuzz=0.9.9 is met. If the fontconfig test does not take place this will avoid the tests for freetype=2.1.5 and xft=2.0.0 and cairo-ft=1.7.6. The consequence is that if your system has the correct fontconfig, freetype, xft and cairo-ft, but no harfbuzz, configure will fail with a configure: error: *** Could not enable any backends. *** Must have at least one backend to build Pango. Instead of a nicer: harfbuzz=0.9.9 requirement not met (after verifying that correct freetype, xft, cairo-ft and fontconfig are installed). With regard to pango-1.34.0, I suppose the message intended (with the dependence on a release candidate fontconfig) is that this pango version should be avoided like the plague unless there is some specific new feature or bug fix which you require to test. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
wild popup bug
This is a follow up on http://comments.gmane.org/gmane.comp.gnome.lib.gtk%2B.devel.apps/31337 I've kept investigating the bug and found that it occurs on any processor, but only when fvwm2 is the WM and the desktop is located beyond the fourth desktop. It does not occur in gtk-2.24, but invariable occurs in GTK+3.4.2 and again in GTK+3.8.0. I'm now quite convinced it is a gtk bug and will try to cook up a simple example to reproduce at will before filing a bug report. Apparently the problem arises from a race with fvwm on accessing XServer information regarding the root window geometry in order to place the popup menu. The bug also happens, in the exact same manner, when placing the tooltip window. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ 3.8.0 released
It would be nice know that =pango1.32.4 means that systems with fontconfig, freetype and xft if and only if harfbuzz = 0.9.9. Seems like the pango 1.32.4 configure.ac tests in things in the wrong order. 2013/3/25 Matthias Clasen matthias.cla...@gmail.com GTK+ 3.8.0 is now available for download at: http://download.gnome.org/sources/gtk+/3.8/ ftp://ftp.gtk.org/pub/gtk/3.8/ sha256 sum: db1345d89d6b5f5bad411b4b2a3b1a18a2a8f98d2ab1b40d43a0197a6e6c252e gtk+-3.8.0.tar.xz What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP), GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation of the GNOME desktop. What's new in 3.8 = Major new features include: * Wayland: - we support Wayland 1.0 now * Broadway: - we install a separate server: broadwayd * Theming: - Improve touch text handle theming - Always draw background of menuitems - The default font is no longer handled like a custom style sheet that overrides everything, but as the initial value. This is the same behavior as in web browsers. - It is now possible to set font-family and font-size like other CSS properties, and relative font sizes are supported. Font sizes in CSS can be specified as numbers or with keywords like xx-small, medium, smaller, larger,... - GtkFrame now draws a background - Opacity can be set on any GtkWidget, not just toplevels * Geometry management - Size groups now handle height-for-width - Fix corner cases in label size allocation - Invisible widgets now return a size of 0x0. This is an experimental change that makes GtkWidget::visible essentially behave the same way that display: none does in CSS. If you want the effect of CSS's visibility: hidden, you can use a GtkNotebook with an empty page * Accessibility - Entry icons are now accessible - We install headers for accessible implementations of GTK+ widgets. This makes it possible to implement accessibility for third-party widgets by subclassing the proper GTK+ implementation. To do so, include gtk/gtk-a11y.h * Touch - We support touch friendly popups on entries and text views in place of context menus, on touch devices * Printing - The print dialog now shows printers that are discovered using avahi, if configured with --enable-avahi-browsing * GtkTreeView and GtkIconView allow single-click activation * We now support the Window Manager frame synchronization protocol draft (when running under a WM that supports it). This means applications will throttle their drawing cycle to what the compositor is drawing, and the compositor will never render half-updated windows, for seamless resizing and improves smoothness in drawing. See https://mail.gnome.org/archives/wm-spec-list/2013-January/msg0.html and the articles at http://blog.fishsoup.net/ for more details. * Performance improvements - Size allocation has been optimized, by avoiding excessive resizing in various situations. - The performance of size groups has been improved. - Text rendering in GtkLabel and other widgets has been optimized to avoid excessive recreation of Pango layouts. - Icon loading overhead was reduced by caching of GtkIconInfo. - The CSS is now keeping a tree of selectors to speed up matchinh. * Deprecations and removals: - Custom CSS properties have been deprecated - Support for color schemes has been removed - gtk_style_provider_get_style, gtk_style_provider_get_icon_factory - GtkGradient and GtkSymbolicColor - All the padding style properties in menus - gtk_style_context_set_direction() has been deprecated in favour of state flags for text direction: GTK_STATE_FLAG_LTR/RTL - gtk_window_set_opacity has been deprecated in favor of gtk_widget_set_opacity * GtkIconInfo has changed from being a boxed type to a GObject. This is technically an ABI change, but basically all existing code will keep working if its used as a boxed type, and its not possible to instantiate GtkIconInfos outside Gtk, so this is not expected to be a big problem. For more details and lists of fixed bugs, see the NEWS file that is included in the tarball,
Re: Confused about GDKPixBuf/Cairo interaction
2013/2/18 Colomban Wendling lists@herbesfolles.org Or maybe I got you wrong and you'd like to *draw* on your GdkPixbuf? I'm afraid this just isn't possible directly. If you really want to do that, you'll probably have to manually do some pixel conversion. You can create a Cairo surface of the pixbuf's size, draw on that, and then get the surface's pixels which you'd convert manually to the pixbuf format, and push those pixels to the pixbuf. But again, why would you need to draw specifically on a GdkPixbuf? Or you could just use Tadej Borovsak's code: http://www.gtkforums.com/viewtopic.php?t=5204 regards! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
FVWM: Fwd: popup menu gtk3 problem.
Hello list, For years I've been a fvwm user and I have a filemanager called Rodent, (http://xffm.org which evolved from the filemanager for xfce versions 4.0 and 4.2). Currently I'm working on a new release and I've come up with a problem which may be fvwm related. On desktops 1-4, everything is fine, but on desktops 5-6 (out of 6 possible), gtk goes haywire trying to determine where to place the popup menu or the tooltip window. A negative value is returned for the window height. Gtk is using XGetWindowProperty() to retrieve the information and sometimes it works, sometimes it does not. So maybe there is a race condition with fvwm... Furthermore, the problem is non-existant if I link the program with gtk2 instead of gtk3. Any help on how to work around this problem will be greatly appreciated. Fvwm compatibility with Rodent filemanager is paramount. $fvwm --version fvwm 2.6.3 compiled on Dec 9 2012 at 06:30:53 with support for: ReadLine, XPM, PNG, SVG, Shape, XShm, SM, XRender, XCursor, XFT, NLS $uname -a Linux areli 3.4.11-tuxonice #4 SMP Sun Dec 16 13:06:43 CST 2012 i686 Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz GenuineIntel GNU/Linux I'm not sure whether this is the appropriate list to post this query or the fvwm-workers should be used instead. If this is the case, please let me know and I will redirect the post. TIA
gtk_menu_popup_for_device() race?
I'm battling with a race condition for several week now, and have not been able to determine anything incorrect in my development code (http:/xffm.org). The situation is as follows: If I compile with gtk+2, everything is fine. Compilation with gtk+3 produces a race condition on mapping the popup menu. The symptoms is that the popup menu acts a little crazy. This condition *only* occurs on my test box with centrino-duo processor, and never on my quad-core box (which indicates a probable race condition). Condition does not always occur, either. The difference gtk+2/gtk+3 is the following (gtk+2.24/gtk+-3.4.4): #if GTK_MAJOR_VERSION3 gtk_menu_popup (menu, NULL, NULL, NULL, NULL, 3, event-time); #else GdkDeviceManager *gdm = gdk_display_get_device_manager (gdk_display_get_default()); gtk_menu_popup_for_device (menu, gdk_device_manager_get_client_pointer(gdm), // GdkDevice *device, NULL, NULL, NULL, NULL, NULL, //GDestroyNotify destroy, 3, event-time); #endif Would the way I'm calling gtk_menu_popup_for_device be causing the problem, or could it be a gtk+3 bug to be reported? Further details on the problem with Valgrind reveal: ==13595== Invalid read of size 4 ==13595==at 0x465DF9C: gdk_x11_screen_get_monitor_workarea (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x4635B1A: gdk_screen_get_monitor_workarea (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x438B103: gtk_menu_get_preferred_height_for_width (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x43879C3: gtk_menu_get_preferred_height (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x44016B3: compute_size_for_orientation (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x44D914D: gtk_window_get_preferred_height (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x44016B3: compute_size_for_orientation (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4401ED5: gtk_widget_get_preferred_size (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x438EAEE: gtk_menu_popup_for_device (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4093AC2: rodent_pop_menu (rodent_popup.c:129) ==13595==by 0x409B315: rodent_signal_on_button_press (rodent_mouse.i:875) ==13595==by 0x437E51E: _gtk_marshal_BOOLEAN__BOXEDv (in /usr/lib/libgtk-3.so.0.400.4) ==13595== Address 0x1b7d6650 is 15 bytes after a block of size 65 alloc'd ==13595==at 0x4029548: malloc (vg_replace_malloc.c:263) ==13595==by 0x40F08D0: XGetWindowProperty (in /usr/lib/libX11.so.6.3.0) ==13595==by 0x465DE84: gdk_x11_screen_get_monitor_workarea (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x4635B1A: gdk_screen_get_monitor_workarea (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x438B103: gtk_menu_get_preferred_height_for_width (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x43879C3: gtk_menu_get_preferred_height (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x44016B3: compute_size_for_orientation (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x44D914D: gtk_window_get_preferred_height (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x44016B3: compute_size_for_orientation (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4401ED5: gtk_widget_get_preferred_size (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x438EAEE: gtk_menu_popup_for_device (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4093AC2: rodent_pop_menu (rodent_popup.c:129) ==13595== Invalid read of size 4 ==13595==at 0x465DF99: gdk_x11_screen_get_monitor_workarea (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x4635B1A: gdk_screen_get_monitor_workarea (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x4392D3F: gtk_menu_item_position_menu (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4387D3E: gtk_menu_position (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x438E913: gtk_menu_popup_for_device (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x438EE59: gtk_menu_popup (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4392B6D: gtk_menu_item_real_popup_submenu (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4392C3B: gtk_menu_item_popup_timeout (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x462582C: gdk_threads_dispatch (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x499C47B: ??? (in /usr/lib/libglib-2.0.so.0.3200.4) ==13595==by 0x499B772: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.3200.4) ==13595==by 0x499BB07: ??? (in /usr/lib/libglib-2.0.so.0.3200.4) ==13595== Address 0x7cbe63c is not stack'd, malloc'd or (recently) free'd Which points to a problem with XGetWindowProperty(). AFAICT, the value returned by XGetWindowProperty() is getting screwed up by some other thread, or, being an asynchronous Xlib instruction, may be out of sync. Any ideas? Further information on problem box: model name : Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz cpu MHz : 1833.000 cache size : 2048 KB flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
Re: gtk_menu_popup_for_device() race?
OK, I know it's bad netiquette to answer your own emails, but I've narrowed the problem down: It so happens that the race condition problem I described (which, BTW, also affects placement of the tooltip window), does not occur on desktops 1-4, but only on 5-6. This is with fvwm (http://fvwm.org) as window manager. So my current hypothesis is that gtk might be using some incorrect parameters in the call to XGetWindowProperty(), or else fvwm might be setting some incorrect parameters or both of them might be racing each other on a common property set in the Xserver. Any other hypothesis? 2013/2/12 Edscott Wilson edscott.wilson.gar...@gmail.com I'm battling with a race condition for several week now, and have not been able to determine anything incorrect in my development code (http:/ xffm.org). The situation is as follows: If I compile with gtk+2, everything is fine. Compilation with gtk+3 produces a race condition on mapping the popup menu. The symptoms is that the popup menu acts a little crazy. This condition *only* occurs on my test box with centrino-duo processor, and never on my quad-core box (which indicates a probable race condition). Condition does not always occur, either. The difference gtk+2/gtk+3 is the following (gtk+2.24/gtk+-3.4.4): #if GTK_MAJOR_VERSION3 gtk_menu_popup (menu, NULL, NULL, NULL, NULL, 3, event-time); #else GdkDeviceManager *gdm = gdk_display_get_device_manager (gdk_display_get_default()); gtk_menu_popup_for_device (menu, gdk_device_manager_get_client_pointer(gdm), // GdkDevice *device, NULL, NULL, NULL, NULL, NULL, //GDestroyNotify destroy, 3, event-time); #endif Would the way I'm calling gtk_menu_popup_for_device be causing the problem, or could it be a gtk+3 bug to be reported? Further details on the problem with Valgrind reveal: ==13595== Invalid read of size 4 ==13595==at 0x465DF9C: gdk_x11_screen_get_monitor_workarea (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x4635B1A: gdk_screen_get_monitor_workarea (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x438B103: gtk_menu_get_preferred_height_for_width (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x43879C3: gtk_menu_get_preferred_height (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x44016B3: compute_size_for_orientation (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x44D914D: gtk_window_get_preferred_height (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x44016B3: compute_size_for_orientation (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4401ED5: gtk_widget_get_preferred_size (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x438EAEE: gtk_menu_popup_for_device (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4093AC2: rodent_pop_menu (rodent_popup.c:129) ==13595==by 0x409B315: rodent_signal_on_button_press (rodent_mouse.i:875) ==13595==by 0x437E51E: _gtk_marshal_BOOLEAN__BOXEDv (in /usr/lib/libgtk-3.so.0.400.4) ==13595== Address 0x1b7d6650 is 15 bytes after a block of size 65 alloc'd ==13595==at 0x4029548: malloc (vg_replace_malloc.c:263) ==13595==by 0x40F08D0: XGetWindowProperty (in /usr/lib/libX11.so.6.3.0) ==13595==by 0x465DE84: gdk_x11_screen_get_monitor_workarea (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x4635B1A: gdk_screen_get_monitor_workarea (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x438B103: gtk_menu_get_preferred_height_for_width (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x43879C3: gtk_menu_get_preferred_height (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x44016B3: compute_size_for_orientation (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x44D914D: gtk_window_get_preferred_height (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x44016B3: compute_size_for_orientation (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4401ED5: gtk_widget_get_preferred_size (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x438EAEE: gtk_menu_popup_for_device (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4093AC2: rodent_pop_menu (rodent_popup.c:129) ==13595== Invalid read of size 4 ==13595==at 0x465DF99: gdk_x11_screen_get_monitor_workarea (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x4635B1A: gdk_screen_get_monitor_workarea (in /usr/lib/libgdk-3.so.0.400.4) ==13595==by 0x4392D3F: gtk_menu_item_position_menu (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4387D3E: gtk_menu_position (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x438E913: gtk_menu_popup_for_device (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x438EE59: gtk_menu_popup (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4392B6D: gtk_menu_item_real_popup_submenu (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x4392C3B: gtk_menu_item_popup_timeout (in /usr/lib/libgtk-3.so.0.400.4) ==13595==by 0x462582C: gdk_threads_dispatch (in /usr/lib/libgdk-3.so.0.400.4) ==13595
Re: Threads and gtk_widget_show (code should not be reached?)
The current method for calling gtk_xx instructions is from the main thread only (i.e., that which owns the main loop context). You can do this by means of g_main_context_invoke(). Otherwise you must use the deprecated gdk_threads_enter/gdk_threads_leave mutex method. The deprecated method is slower. If you do not do the above, you will get all sort of errors just like the one you describe. HTH 2013/1/30 Ferdinand Ramirez ramirez.ferdin...@yahoo.com I have encountered a strange error followed by a crash when I add the following object to a GtkTextView by creating a child anchor and call gtk_widget_show_all. The object that is added The object that is added to the child anchor is a GtkFrame inside which is a GtkTable and each cell of the table contains another GtkFrame each of which contains a GtkTextView. The error This works fine if it is all done from the main program. However, when I create the hierarchy described above in another thread and call gtk_widget_show_all on the GtkFrame that is added, I get an error in paint saying code should not be reached. Before this error, there is a warning that the iterator in text view has changed. I am not sure if the warning and error are related. Source of the error I replaced gtk_widget_show_all by gtk_widget_show in a loop going down the tree and calling it for each object. The source of the error was the gtk_widget_show on the leaf level view objects in the frames contained in each cell of the table. Situations under which it works When the leaf level GtkTextView objects are not part of the hierarchy of widgets I create or they are replaced by GtkEntry objects, everything works fine. Again, note that it also works fine if I do not have another thread and call everything from the main program on startup but I need to have another thread as this object will be created during the course of the program. I've tried both g_idle_add as well as using the gdk_threads_enter/leave pair. Any help will be appreciated. -Ferdinand ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Threads and gtk_widget_show (code should not be reached?)
BTW, g_main_context_invoke() will be erratic if you do not have the main context loop running. This is common at startup, when you do all sort of gtk_xx before entering the main loop. Solution: start the loop as soon as possible in the main thread, and anything else the main thread needs to do, put in a g_idle function. 2013/1/30 Edscott Wilson edscott.wilson.gar...@gmail.com The current method for calling gtk_xx instructions is from the main thread only (i.e., that which owns the main loop context). You can do this by means of g_main_context_invoke(). Otherwise you must use the deprecated gdk_threads_enter/gdk_threads_leave mutex method. The deprecated method is slower. If you do not do the above, you will get all sort of errors just like the one you describe. HTH 2013/1/30 Ferdinand Ramirez ramirez.ferdin...@yahoo.com I have encountered a strange error followed by a crash when I add the following object to a GtkTextView by creating a child anchor and call gtk_widget_show_all. The object that is added The object that is added to the child anchor is a GtkFrame inside which is a GtkTable and each cell of the table contains another GtkFrame each of which contains a GtkTextView. The error This works fine if it is all done from the main program. However, when I create the hierarchy described above in another thread and call gtk_widget_show_all on the GtkFrame that is added, I get an error in paint saying code should not be reached. Before this error, there is a warning that the iterator in text view has changed. I am not sure if the warning and error are related. Source of the error I replaced gtk_widget_show_all by gtk_widget_show in a loop going down the tree and calling it for each object. The source of the error was the gtk_widget_show on the leaf level view objects in the frames contained in each cell of the table. Situations under which it works When the leaf level GtkTextView objects are not part of the hierarchy of widgets I create or they are replaced by GtkEntry objects, everything works fine. Again, note that it also works fine if I do not have another thread and call everything from the main program on startup but I need to have another thread as this object will be created during the course of the program. I've tried both g_idle_add as well as using the gdk_threads_enter/leave pair. Any help will be appreciated. -Ferdinand ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Would this leak be inside gtk?
I've just verified with tcmalloc that there is no leak in gtk_combo_box_new_with_entry(), on x86. The issue is with Valgrind which gets confused with concurrent threads. Although the spaguetti output pprof is a bit confusing at first, once you look through the documentation the diagrams are very helpful. Issue solved. Thanks. 2013/1/23 Andrew Potter agpot...@gmail.com On Wed, Jan 23, 2013 at 1:38 PM, Edscott Wilson edscott.wilson.gar...@gmail.com wrote: Maybe it's just a bug in Valgrind... I'm finding that a threaded environment may confuse Valgrind. I'll do some more checking. In Valgrind threads become serialized, there is no true concurrency. I found a lot more success hunting memory leaks using Google's tcmalloc library. To use the heapcheck feature, you'll need to run your program on a x86 platform (a VM x86 on x86_64 works). tcmalloc on x86_64 does not provide the requisite stack traces. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Would this leak be inside gtk?
I conclude this is a gtk memory leak. It occurs when calling
gtk_combo_box_new_with_entry(), Apparently, when the dialog that contains
the combo box is destroyed, the GList visible_children in file
gtkcombobox.c is not being cleansed of the pointer to the child widget,
entry. The leak does not occur if plain gtk_combo_box_new() is used
instead. Correct me if I'm wrong.
Here's a valgrind suppression entry:
{
libgtk:comboboxwithentry
Memcheck:Leak
fun:malloc
fun:g_malloc
fun:g_slice_alloc
fun:g_list_prepend
fun:gtk_combo_box_get_path_for_child
fun:gtk_widget_get_path
fun:reset_style_recurse
fun:gtk_widget_set_parent
fun:gtk_combo_box_add
fun:g_closure_invoke
}
2013/1/22 Edscott Wilson edscott.wilson.gar...@gmail.com
Would the following be a leak in the gtk library (which I should not worry
about), or a leak in my program ( http://xffm.org )?
==19528==
==19528== 24 bytes in 1 blocks are definitely lost in loss record 2,773 of
9,919
==19528==at 0x4C2AABB: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==19528==by 0x8993114: g_malloc (in /usr/lib64/libglib-2.0.so.0.3000.2)
==19528==by 0x89A8069: g_slice_alloc (in
/usr/lib64/libglib-2.0.so.0.3000.2)
==19528==by 0x8986F8D: g_list_prepend (in
/usr/lib64/libglib-2.0.so.0.3000.2)
==19528==by 0x5EF1E9A: gtk_combo_box_get_path_for_child (in
/usr/lib64/libgtk-3.so.0.200.4)
==19528==by 0x60AC65B: gtk_widget_get_path (in
/usr/lib64/libgtk-3.so.0.200.4)
==19528==by 0x60AC6F9: reset_style_recurse (in
/usr/lib64/libgtk-3.so.0.200.4)
==19528==by 0x60B8276: gtk_widget_set_parent (in
/usr/lib64/libgtk-3.so.0.200.4)
==19528==by 0x5EF1F83: gtk_combo_box_add (in
/usr/lib64/libgtk-3.so.0.200.4)
==19528==by 0x8300C63: g_closure_invoke (in
/usr/lib64/libgobject-2.0.so.0.3000.2)
==19528==by 0x83173A6: ??? (in /usr/lib64/libgobject-2.0.so.0.3000.2)
==19528==by 0x8318DE8: g_signal_emit_valist (in
/usr/lib64/libgobject-2.0.so.0.3000.2)
Gtk version: GTK+-3.2.4
Linux tauro 3.2.1-gentoo-r2 #3 SMP Tue Oct 16 09:47:16 CDT 2012 x86_64
Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux
Any clues will be kindly appreciated.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Would this leak be inside gtk?
2013/1/23 David Nečas y...@physics.muni.cz Whether gtk_combo_box_get_path_for_child() can be called with a visible child different from those enumerated there (the only way a leak can occur) I cannot tell. In any case, any suspected leak that goes through GSlice should be first reproduced with G_SLICE=always-malloc -- and you find it real, a bug report is much better than suppression... I did use G_SLICE=always-malloc. Strange thing is that on another program (rodent-fgr) there is no leak with the creation of combobox with entry. The only difference is that in rodent-fgr, all work is done by the main thread and the combobox is in the main window, while in rodent, the work is invoked from a non-main thread by means of a g_main_context_invoke() and the combobox is in a dialog. Maybe it's just a bug in Valgrind... I'm finding that a threaded environment may confuse Valgrind. I'll do some more checking. Edscott ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Would this leak be inside gtk?
Would the following be a leak in the gtk library (which I should not worry about), or a leak in my program ( http://xffm.org )? ==19528== ==19528== 24 bytes in 1 blocks are definitely lost in loss record 2,773 of 9,919 ==19528==at 0x4C2AABB: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==19528==by 0x8993114: g_malloc (in /usr/lib64/libglib-2.0.so.0.3000.2) ==19528==by 0x89A8069: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.3000.2) ==19528==by 0x8986F8D: g_list_prepend (in /usr/lib64/libglib-2.0.so.0.3000.2) ==19528==by 0x5EF1E9A: gtk_combo_box_get_path_for_child (in /usr/lib64/libgtk-3.so.0.200.4) ==19528==by 0x60AC65B: gtk_widget_get_path (in /usr/lib64/libgtk-3.so.0.200.4) ==19528==by 0x60AC6F9: reset_style_recurse (in /usr/lib64/libgtk-3.so.0.200.4) ==19528==by 0x60B8276: gtk_widget_set_parent (in /usr/lib64/libgtk-3.so.0.200.4) ==19528==by 0x5EF1F83: gtk_combo_box_add (in /usr/lib64/libgtk-3.so.0.200.4) ==19528==by 0x8300C63: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.3000.2) ==19528==by 0x83173A6: ??? (in /usr/lib64/libgobject-2.0.so.0.3000.2) ==19528==by 0x8318DE8: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.3000.2) Gtk version: GTK+-3.2.4 Linux tauro 3.2.1-gentoo-r2 #3 SMP Tue Oct 16 09:47:16 CDT 2012 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux Any clues will be kindly appreciated. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Hdf-forum] hdf5 1.8.9 on mingw made easy.
The two patches address three issues with the mingw compilation for
non-CMake guys.
To start with, the check for wsock lib would make the patch line:
LIBS=($libs -lwsock32)
obsolete (AC_CHECK_LIB is the right way to do things). I took a shortcut
to get it working right away.
Following that, adding a check to set HAVE_WINDOWS, HAVE_WIN32_API should
be no problem either. There are several alternatives.
The third issue, on whether to add H5FDwindows.c,h to the build process
would taken care of with CMake with modification of the CMakeLists.txt. But
this file is ignored with a simple autotools build. I don't see how to
avoid the use of the automake conditional in the modified Makefile.am. As
usual, there are several options to resolve the conditional in the
configure script.
regards!
2012/7/19 Allen D Byrne b...@hdfgroup.org
The next release of HDF5 is this fall with the code freeze at the end of
September.
The current code base in svn (including the cmake branch) already works on
Windows 7 and mingw using cmake, with the exception of fortran.
I will work with the autotools experts to review these patches with the
changes I already made (added check for the wsock lib).
My version of mingw on Windows 7 will not generate the h5pubconf.h file
properly (verbatim copy of the config.in file),
and that has prevented me from finishing the support for mingw.
Allen
On Wednesday, July 18, 2012 10:51:52 PM Michael Jackson wrote:
If we added these features to the CMake scripts would that help also? I
am
more of a CMake Guy than an autotools guy but I would think adding these
flags to the CMake files for MinGW would allow one to configure HDF5 with
CMake
on MinGW (or MSYS).
Thoughts? When is the next release of HDF5 scheduled for? Not sure I am
going to have time to patch before mid August.
___
Mike JacksonPrincipal Software Engineer
BlueQuartz SoftwareDayton, Ohio
mike.jack...@bluequartz.net www.bluequartz.net
On Jul 18, 2012, at 6:05 PM, edscott wilson garcia wrote:
Hi forum,
In order to get hdf5 1.8.9 to compile cleanly with no fuzz on mingw,
just patch two files, configure.in and src/Makefile. Then regenerate
scripts with
aclocal autoheader libtoolize automake autoconf.
Finally run configure with the option --with-mingw, compile and
enjoy.
The patches are very simple:
Patch for configure.in
***
--- /tmp/hdf5-1.8.9/configure.in.old2012-05-09 10:07:27.0
-0500
+++ /tmp/hdf5-1.8.9/configure.in2012-07-18 16:51:35.0
-0500
@@ -49,6 +49,16 @@
dnl rebuild rules.
AM_MAINTAINER_MODE
+AC_ARG_WITH(mingw, [--with-mingwenable compilation with gnu gcc
under
mingw])
+AM_CONDITIONAL([WITH_MINGW], [test $with_mingw = yes])
+if test $with_mingw = yes; then
+ AC_DEFINE([HAVE_WINDOWS],[1],[Define if the Windows virtual file
driver
should be compiled])
+ AC_DEFINE([HAVE_MINGW],[1],[Define if on mingw])
+ AC_DEFINE([HAVE_WIN32_API],[1],[Define if on the Windows platform])
+dnl We also need to add a -lwsock32 to avert _WSAStartup@8 errors
+ LIBS=$LIBS -lwsock32
+fi
+
dnl Run post processing on files created by configure.
dnl src/H5pubconf.h:
dnl Generate src/H5pubconf.h from src/H5config.h by prepending H5_ to
all
Patch for src/Makefile.am
***
--- /tmp/hdf5-1.8.9/src/Makefile.am.old2012-05-09
10:05:58.0
-0500
+++ /tmp/hdf5-1.8.9/src/Makefile.am2012-07-18 16:54:27.0
-0500
@@ -103,6 +103,9 @@
H5Zdeflate.c H5Zfletcher32.c H5Znbit.c H5Zshuffle.c H5Zszip.c
\
H5Zscaleoffset.c H5Ztrans.c
+if WITH_MINGW
+ libhdf5_la_SOURCES+=H5FDwindows.c
+endif
# Public headers
include_HEADERS = hdf5.h H5api_adpt.h H5overflow.h H5pubconf.h
H5public.h
H5version.h \
@@ -115,6 +118,10 @@
H5MMpublic.h H5Opublic.h H5Ppublic.h H5Rpublic.h H5Spublic.h \
H5Tpublic.h H5Zpublic.h
+if WITH_MINGW
+ libhdf5_la_SOURCES+=H5FDwindows.h
+endif
+
# install libhdf5.settings in lib directory
settingsdir=$(libdir)
settings_DATA=libhdf5.settings
___
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
___
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
___
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
[Hdf-forum] hdf5 1.8.9 on mingw made easy.
Hi forum, In order to get hdf5 1.8.9 to compile cleanly with no fuzz on mingw, just patch two files, configure.in and src/Makefile. Then regenerate scripts with aclocal autoheader libtoolize automake autoconf. Finally run configure with the option --with-mingw, compile and enjoy. The patches are very simple: Patch for configure.in *** --- /tmp/hdf5-1.8.9/configure.in.old2012-05-09 10:07:27.0 -0500 +++ /tmp/hdf5-1.8.9/configure.in2012-07-18 16:51:35.0 -0500 @@ -49,6 +49,16 @@ dnl rebuild rules. AM_MAINTAINER_MODE +AC_ARG_WITH(mingw, [--with-mingwenable compilation with gnu gcc under mingw]) +AM_CONDITIONAL([WITH_MINGW], [test $with_mingw = yes]) +if test $with_mingw = yes; then + AC_DEFINE([HAVE_WINDOWS],[1],[Define if the Windows virtual file driver should be compiled]) + AC_DEFINE([HAVE_MINGW],[1],[Define if on mingw]) + AC_DEFINE([HAVE_WIN32_API],[1],[Define if on the Windows platform]) +dnl We also need to add a -lwsock32 to avert _WSAStartup@8 errors + LIBS=$LIBS -lwsock32 +fi + dnl Run post processing on files created by configure. dnl src/H5pubconf.h: dnl Generate src/H5pubconf.h from src/H5config.h by prepending H5_ to all Patch for src/Makefile.am *** --- /tmp/hdf5-1.8.9/src/Makefile.am.old2012-05-09 10:05:58.0 -0500 +++ /tmp/hdf5-1.8.9/src/Makefile.am2012-07-18 16:54:27.0 -0500 @@ -103,6 +103,9 @@ H5Zdeflate.c H5Zfletcher32.c H5Znbit.c H5Zshuffle.c H5Zszip.c \ H5Zscaleoffset.c H5Ztrans.c +if WITH_MINGW + libhdf5_la_SOURCES+=H5FDwindows.c +endif # Public headers include_HEADERS = hdf5.h H5api_adpt.h H5overflow.h H5pubconf.h H5public.h H5version.h \ @@ -115,6 +118,10 @@ H5MMpublic.h H5Opublic.h H5Ppublic.h H5Rpublic.h H5Spublic.h \ H5Tpublic.h H5Zpublic.h +if WITH_MINGW + libhdf5_la_SOURCES+=H5FDwindows.h +endif + # install libhdf5.settings in lib directory settingsdir=$(libdir) settings_DATA=libhdf5.settings ___ Hdf-forum is for HDF software users discussion. Hdf-forum@hdfgroup.org http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
Bug#660241: libhypre-2.4.0: should be two packages: libhypre-openmpi and libhypre-mpich2
Hello, 2012/2/21 Adam C Powell IV hazel...@debian.org tags 660241 moreinfo thanks Hello, On Fri, 2012-02-17 at 09:37 -0600, Edscott Wilson Garcia wrote: Package: libhypre-2.4.0 Version: 2.4.0b-7 Severity: important Hypre works fine with mpich2. Instalation via debian package invariably ties it up with openmpi. When target user has a preference for mpich2 (or a specific need for mpich2), the libhypre debian package is no good. Package should be constructed in the manner of libhdf5, which provides the virtual package libhdf5 from both libhdf5-openmpi.deb and libhdf5-mpich2.deb. Please be more specific: exactly how is the libhypre package no good with mpich2? Looking at the Buildd on sparc, for example, it builds just fine using mpich2, and lots of other reverse-depends (petsc, slepc, elmerfem, etc.) build just fine too. Exactly. hypre builds without problems with mpich2. That's precisely my point. What I have my finger on is on the user end, not the developer who has no problem building hypre however. Let me clarify this with an example. Say you have a group of developers who are developing an oil reservoir simulation program based on hypre. These developers may or may not be using a debian distro. Once the software is finished, it will be installed on computers belonging to petroleum engineers with little knowledge as to the inner working of the simulator. The intended platform is debian stable, on amd64/i386, because it is a good linux distribution for this user profile. The simulation software may not have hypre linked in statically (so say the lawyers of the oil company) and must be linked dynamically with the system installed hypre. This has to be installed from a debian binary package. The current debian binary package requires openmpi. But there might be another package on the users computer that uses mpich2 (say some parallel hdf5 software). If there were separate binary packages for openmpi/mpich2 (as with the hdf5 binary package), the debian stable platform would remain very attractive. The purpose of mpi-defaults is that we compile each package only once using the MPI implementation relevant for that platform. This cuts the archive disk bloat and build time in half, or sometimes better -- by a factor of 4 if HDF5 would adopt this method, since they still build with deprecated mpich and lam. Sure, mpich and lam are deprecated, but the issue here is mpich2, which is definitely not deprecated. If there is no particular reason for separating this into different packages, I'm going to downgrade this to wishlist and tag it wontfix. There is a particular reason, as exposed before. I do have an important user base down the road that will need to use hypre and need to be able to choose between either openmpi or mpich2. These users should *not* be required to build hypre. If you tag the bug as wontfix, then I'll have to go ahead and build the debian packages and publish them on sourceforge. Another debian developer suggested I file a bug report before doing this. You're on amd64, so why are you concerned about hypre on non-OpenMPI platforms? The software I'm concerned with is not for me. I always compile from source. My concern is for others in a effort to make things more robust. I appreciate your time and response, and will be grateful if you weigh my point of view. Edscott
Bug#660241: libhypre-2.4.0: should be two packages: libhypre-openmpi and libhypre-mpich2
Package: libhypre-2.4.0 Version: 2.4.0b-7 Severity: important Hypre works fine with mpich2. Instalation via debian package invariably ties it up with openmpi. When target user has a preference for mpich2 (or a specific need for mpich2), the libhypre debian package is no good. Package should be constructed in the manner of libhdf5, which provides the virtual package libhdf5 from both libhdf5-openmpi.deb and libhdf5-mpich2.deb. -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libhypre-2.4.0 depends on: ii libatlas3gf-base [liblapa 3.8.3-27 Automatically Tuned Linear Algebra ii libblas3gf [libblas.so.3g 1.2-8 Basic Linear Algebra Reference imp ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libopenmpi1.3 1.4.2-4high performance message passing l ii libstdc++64.4.5-8The GNU Standard C++ Library v3 ii libsuperlu3 3.0+20070106-3 Direct solution of large, sparse s libhypre-2.4.0 recommends no packages. libhypre-2.4.0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[Hdf-forum] 1.8.8 debian packages
Hello all, Current debian packages for hdf5 are quite out of date and I needed to install hdf5 library on several users' computer in order to test a simulation software. And the installation had to be from binary package in the conventional manner. So I went ahead and prepared debian packages for 1.8.8 in both amd64 and i386 architectures. These packages are available for download at: http://sourceforge.net/projects/dbh/files/hdf5/ Specifications: - debian package format i386/amd64 - configured in serial mode - includes the C++ development - does not include Fortran development (if your program has F code, this library is only good for runtime) - Configure scripts and makefiles were rebuilt on: Linux tauro 3.0.6-gentoo #2 SMP Wed Oct 26 11:25:14 CDT 2011 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux - debian package build on debian 6 (squeeze) but they should be fine in Ubuntu. - publication date: 2012-02-03 - distribution of this package by no way endorses or promotes HDF5 - all other hdf5-group copyright specifications (listed at above mentioned download site) apply enjoy! ___ Hdf-forum is for HDF software users discussion. Hdf-forum@hdfgroup.org http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
RFS: Rodent Beta filemanager
From: Edscott Wilson Garcia edscott.wilson.gar...@gmail.com To: debian-mentors@lists.debian.org Subject: RFS: rodent Dear mentors, I am looking for a sponsor for my package rodent. * Package name: rodent Version : 4.6.2 Upstream Author : edsc...@xfce.org * URL : http://rodent.xffm.org/ * License : GPL-v3 Section : utils It builds these binary packages: rodent - Advanced user filemanager for Linux/BSD systems The package appears to be lintian clean. My motivation for maintaining this package is: I am the upstream maintainer. You can find more information about this project at http://rodent.xffm.org and at the sourceforge resource http://sourceforge.net/projects/xffm/ The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/rodent - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/rodent/rodent_4.6.2.dsc I would be glad if someone uploaded this package for me. Kind regards Edscott Wilson Garcia
Re: FVWM: Plans for Drag-N-Drop menus and Desktop Icons?
On Mon, 24 Apr 2006, Michelle Konzack wrote: Hello Renato, Am 2006-04-22 12:46:11, schrieb seventh guardian: I did ask for some kind of support for this a while ago. Since then I got used to not having it, but even so ended up using rox as a desktop app. You can also use xffm-4.3 which is compatible with fvwm-root, and also contains an extension of fvwm-root (called xffm-root) which is linked with gdkpixbuf library and allows a wider range of formats for background images. Here's a screenshot of fvwm in combination with xffm-deskview: http://xffm.sourceforge.net/screenshots/xffm-deskview-screenshot.png xffm-5.0 should be released in a month or two, without any xfce dependencies.
Re: The LyX licence --- a gentle nudge
Permission granted :-) El mié, 30-03-2005 a las 10:57 +0100, Angus Leeming escribió: Dear all, please excuse the personal email, but I'm trying to do something about the messy state of the LyX licence and need your help. LyX is currently licenced under the GPL with a huge hole blowing it wide apart so that it could be linked against the closed source XForms library. See http://www.lyx.org/about/license.php3. Legal opinion has it that this exception does not apply only to the XForms library. Instead, anything and everything is allowed to link against the LyX source code, defeating the whole point and purpose of the GPL. Moreover, the exception is no longer needed as XForms (and indeed Qt) are available under the GPL. To make a messy situation even messier, it's not even certain whether the current license is valid at all, as the necessary permissions may not have been obtained before the change was made to the original GPL. In light of all this, I'm asking whether I can have your permission to add your names to http://www.lyx.org/blanket-permission.txt : The following people hereby grant permission to licence their contributions to LyX under the Gnu General Public Licence, version 2 or later. so that we can have a permanent record of those people who have contributed code to LyX and who are happy for this code to be licenced under the GPL. Kind regards, Angus ps, if you reply to lyx-devel@lists.lyx.org, we'll have a permanent record of your response. -- Edscott Wilson Garcia [EMAIL PROTECTED]
Re: The LyX licence --- a gentle nudge
Permission granted :-) El mié, 30-03-2005 a las 10:57 +0100, Angus Leeming escribió: > Dear all, > > please excuse the personal email, but I'm trying to do something about > the messy state of the LyX licence and need your help. > > LyX is currently licenced under the GPL with a huge hole blowing it > wide apart so that it could be linked against the closed source > XForms library. See http://www.lyx.org/about/license.php3. Legal > opinion has it that this exception does not apply only to the XForms > library. Instead, anything and everything is allowed to link against > the LyX source code, defeating the whole point and purpose of the > GPL. Moreover, the exception is no longer needed as XForms (and > indeed Qt) are available under the GPL. > > To make a messy situation even messier, it's not even certain whether > the current license is valid at all, as the necessary permissions may > not have been obtained before the change was made to the original > GPL. > > In light of all this, I'm asking whether I can have your permission to > add your names to http://www.lyx.org/blanket-permission.txt : > > "The following people hereby grant permission to licence their > contributions to LyX under the Gnu General Public Licence, version 2 > or later." > > so that we can have a permanent record of those people who have > contributed code to LyX and who are happy for this code to be > licenced under the GPL. > > Kind regards, > Angus > > ps, if you reply to lyx-devel@lists.lyx.org, we'll have a permanent > record of your response. > -- Edscott Wilson Garcia <[EMAIL PROTECTED]>
Re: Accelerators don't work
El mié, 29-09-2004 a las 10:46, Pramod Patangay escribió: Hi All, I am trying to add accelerators to menu items. But they don't seem to work as they should. There's a menuitem which when activated will hide the menu bar. But once the menu bar is hidden, none of the accelerators work. I am using Fedora Core. Any idea on what's going on here? Why are accelerators disabled when menu bar is hidden? How do I enable them? and what are the other workarounds? Suprisingly I don't face this problem on RedHatLinux-8 but only on FedoraCore. I've got the same problem (Gentoo-linux with gtk-2.4). This fault is either a bug or the gtk developers decided that accelerators to hidden menu items is not a valid way to code. I'm not sure, but probably the latter is correct. To work around this issue, you could add in your own keypress event handlers. When you get a hit for a key that should accelerate to the hidden menu item, just go to the callback directly and return TRUE, otherwise FALSE. Edscott ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
gtktreeview bug or feature?
I've noticed that with gtk-2.4 (gentoo) while the mouse cursor goes over the expander of a row in a treeview, the expander changes to white (in gtk2.2 it would change to black). Is this a bug or a feature? I suppose it is a feature if you could select the color you wish to use to indicate the mouse is over the expander, but I have not found out how to do so. Edscott Wilson Garcia ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
treeview and left hand mouse
Is there any way to swap mouse buttons 1 and 3 for left hand people within a gtk2 app? In particular I'm looking to be able to expand/collapse treeview nodes without messing with the private gtk stuff used to determine if the click occurred on the expander symbol. TIA, Edscott Wilson Garcia ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Problem with GtkTreeModel, simultaneous iterating and append
On Mon, 2003-10-20 at 08:49, Boszormenyi Zoltan wrote:
Hi,
is it possible to append a row to a TreeModel while having
an iterator going through the same model?
Probably a hack but... if you append the row to a treepath greater than
that of the iterator, no problem. But if you append it to a path less
than that represented by the iterator, the iterator will be knocked off
track. That's just what I've observed.
Edscott
I have a code snippet that does just the same,
the second time the code runs
the second gtk_tree_model_get_iter_first() seems to succeed
but gives an invalid iterator, as I get invalid values.
I use an uptodate fedora core, gtk2-2.2.4-5.1.
This is the code:
void utolso_sztorno(void) {
GtkTreeIter iter, iter1;
int sorsz, sorsz1, lancfej, lancresz, gyujto, afa,
prev, next;
gchar *tranz, *vk, *nev, *afajel, *egys;
double szorzo, ar, osszeg;
if (gtk_tree_model_get_iter_first(GTK_TREE_MODEL(ptgdb_internal-tetelek),
iter)) {
do {
gtk_tree_model_get (GTK_TREE_MODEL(ptgdb_internal-tetelek),
iter,
TETEL_SORSZ, sorsz, TETEL_PREV, lancresz, -1);
if (!lancresz)
lancfej = sorsz;
} while (gtk_tree_model_iter_next
(GTK_TREE_MODEL(ptgdb_internal-tetelek), iter));
#if 0 /* makes no difference */
memset(iter, 0, sizeof(iter));
#endif
if
(gtk_tree_model_get_iter_first(GTK_TREE_MODEL(ptgdb_internal-tetelek), iter))
do {
gtk_tree_model_get (GTK_TREE_MODEL(ptgdb_internal-tetelek),
iter,
TETEL_SORSZ, sorsz1, TETEL_TRANZAK, tranz,
TETEL_VKOD, vk, TETEL_NEV, nev,
TETEL_GYUJTO, gyujto, TETEL_AFA, afa,
TETEL_AFAJEL, afajel, TETEL_SZORZO, szorzo,
TETEL_EGYSEG, egys, TETEL_AR, ar,
TETEL_OSSZEG, osszeg, TETEL_PREV, prev,
TETEL_NEXT, next, -1);
/* here I get invalid numbers on the second run, seems to be un-initialized */
printf(sorsz: %d\n, sorsz1);
if (sorsz1 sorsz)
break;
if ((sorsz1 = lancfej) (sorsz1 = sorsz)) {
gtk_list_store_set (ptgdb_internal-tetelek,
iter1, TETEL_SZTORNO, TRUE,
osszeg, -1);
gtk_list_store_append (ptgdb_internal-tetelek,
iter1);
gtk_list_store_set(ptgdb_internal-tetelek, iter1,
TETEL_SORSZ, sorsz1 + sorsz - lancfej + 1,
TETEL_TRANZAK, tranz,
TETEL_VKOD, vk, TETEL_NEV, nev,
TETEL_SZTORNO, TRUE, TETEL_IGAZITAS, 1.0,
TETEL_GYUJTO, gyujto,
TETEL_AFA, afa, TETEL_AFAJEL, afajel,
TETEL_SZORZO, -szorzo,
TETEL_EGYSEG, egys,
TETEL_AR, ar, TETEL_OSSZEG, -osszeg,
TETEL_PREV, prev, TETEL_NEXT, next,
-1);
}
} while (gtk_tree_model_iter_next
(GTK_TREE_MODEL(ptgdb_internal-tetelek), iter1));
} else
gdk_beep();
}
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
passing events to userland
Hi, I'm using Hiroyuki's toshiba_acpi patch (posted on the freebsd-mobile list), and it captures the extra buttons for acpi settings. I want to use such events to do things in userland. Does anybody know how to pass make a kernel module generate a specific keypress event in userland? Any ideas or pointers to where to look will be greatly appreciated. Maybe there is some kernel module that I can examine the code? Using 5.1-RELEASE. regards, Edscott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: passing on signals
On Tue, 2003-09-30 at 20:09, edscott wilson garcia wrote: Hi, Does anybody know the correct way to pass on keypressed signals received by one widget to another? Either of the following two lines causes gtk to segfault when signal received by GtkCombo is passed to GtkEntry: gtk_signal_emit_by_name (GTK_OBJECT (entry), key_press_event,event,data,NULL); gtk_signal_emit_by_name (GTK_OBJECT (entry), key_press_event,event,data); If anyone is interested, I figured this one out: gtk_signal_emit_by_name() is blocking, i.e. it does not return until the signal has been duly received and processed by the target widget's signal handler. And the value of data is overwritten by the return of the signal handler (in this case it returns a guint). This means that you must save whatever you have in data to restore it after the function returns. But the fact that gtk_signal_emit_by_name() is blocking means that you have to get into the thread business if you want to make things work as with signal queue. So you are much better off calling the signal handler of the signalled widget directly. Oh well... Edscott TIA, Edscott Wilson Garcia ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: passing on signals
Thanks for the clarification, Sven. I suppose the additional parameter after event will make the call blocking so that the return value of the signal handler can be returned there, and if there is no additional parameter (or set to NULL) the function will just toss the signal on to the queue to be processed by the event loop and be non-blocking. Just a hypothesis... On Thu, 2003-10-02 at 14:04, Sven Neumann wrote: Hi, edscott wilson garcia [EMAIL PROTECTED] writes: Does anybody know the correct way to pass on keypressed signals received by one widget to another? Either of the following two lines causes gtk to segfault when signal received by GtkCombo is passed to GtkEntry: gtk_signal_emit_by_name (GTK_OBJECT (entry), key_press_event,event,data,NULL); gtk_signal_emit_by_name (GTK_OBJECT (entry), key_press_event,event,data); Both lines are wrong. The user_data that is passed to a signal callback is not set on signal emission but it's the data set when the signal was connected. The correct code would be: gtk_signal_emit_by_name (GTK_OBJECT (entry), key_press_event, event); Actually this is deprecated API, so you would better use the following instead: g_signal_emit_by_name (entry, key_press_event, event); This code assumes that event is a pointer to a GdkEventKey structure. Sven ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
deprecated GtkCombo
This is what I hear from Owen: +--- Additional Comments From [EMAIL PROTECTED] 2003-10-02 15:08 --- +I don't know what you mean set as a user signal handler + +But connecting to events on combo-popwin is certainly not +legitimate. + +And in any case GtkCombo is being deprecated for GTK+-2.4, Does anybody know what to use instead? ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: deprecated GtkCombo
On Thu, 2003-10-02 at 14:55, Owen Taylor wrote: There is a new GtkComboBox widget in CVS which will replace GtkCombo and GtkOptionMenu for GTK+-2.4. But what I was saying was not that you should be using something different, but rather saying that RFE's for GtkCombo won't be accepted. And your bug report was an RFE - I want to be able to catch key press events on combo-popwin and change them to do something different than what the widget would normally do. I really have no idea what you were trying to accomplish, but I doubt it was essential to the operation of your user interface... generally GTK+ programming is the art of combining existing standard elements to make a nice user interface. I was trying to accomplish something rather simple: The popup should appear and change according to what input is fed into the entry, much as what happens with the mozilla location entry. For this I pass the keyboard input from the popwin to the entry. It works great (you can see it in action in xffm, available from CVS, cvs.xfce.sourceforge.net). The only glitch is that it takes 2 returns to accomplish what mozilla does with one, because the popwin signal handler does not let the return key through (although it lets most everything else pass). Oh well, I guess I must create a private structure grouping an entry, a popwin and a GList. Bad news. regards, Edscott Apparently the combo popwin should not let any keypress signal through Regards, Owen ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
passing on signals
Hi, Does anybody know the correct way to pass on keypressed signals received by one widget to another? Either of the following two lines causes gtk to segfault when signal received by GtkCombo is passed to GtkEntry: gtk_signal_emit_by_name (GTK_OBJECT (entry), key_press_event,event,data,NULL); gtk_signal_emit_by_name (GTK_OBJECT (entry), key_press_event,event,data); TIA, Edscott Wilson Garcia ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (no subject)
On Wed, 2003-09-17 at 15:05, Philippe wrote: Hello, I've got a dialog with three treeviews and one treemodel filled with the names of all the users for the system. I'd like the three treeviews to use the same treemodel. yet they must not display the same users. my question is : is there a way to filter the rows of a treemodel which are goint to be displayed by a particular treeview?? AFAIK, no. But you can hack away by defining a treemodel with a bunch of columns. Treeview A would show users in column A, Treeview B would show column B, Treeview C would show column C. Each extra column of your treemodel would also have to be triplicate to associate to A, B or C. Then you would have to deal with empty rows when the number of users % 3 != 0. Probably not a good idea... Thanks for any help Philippe Rouquier ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: TreeView width?
On Wed, 2003-09-17 at 07:07, Igor Gorbounov wrote: Hi, All! Is there any reliable method for calculating the size of a filled TreeView before showing it, for proper setting the size of a window containing this treeview? get_width() for TreeViewColumns returns 0, get_width() for the treeview itself returns a significant lesser value, cell_get_size(...) returns very small widths, pango_layout gives the proper values for text size in cells, but it knows nothing about white spaces between columns and I have to scan all rows for every column to get the maximum size. So how normal folks are doing this? Using gtk autosize features to get appropriate size? Igor Gorbounov ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
GtkCombo with active glist
Does anybody how to have a gtkCombo where the associated GList is visible the entry is receiving keyboard input? I mean, something like what you see in mozilla while typing something into the location entry? Can that behaviour be achieved in gtk without some ugly hack? TIA Edscott ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkTreeModel
On Sun, 2003-08-31 at 13:27, Christer Palm wrote: Hi! A question for all you GtkTreeModel wizards out there; I have implemented a custom GtkTreeModel to model a directory tree. For obvious performance reasons, I need to delay the scanning of a subdirectory until the user actually expands it. Thus, all directories will initially be assumed to contain subdirectories (i.e. my gtk_tree_model_iter_has_child() implementation speculatively returns true). The tricky part is what happens if the user tries to expand a subdirectory which doesn't happen to contain any subdirectories. Just like the Windoze explorer (cough) directory view, I want the expander for that directory to magically disappear when the user tries to expand it. Use gtktreestore model. Add a dummy for non expanded directories. That makes the expander appear. When the user expands, if nothing is in there, collapse the node and remove the dummy. Since there will be no children, the expander disappears. But what would you do if some other process or whatever creates a file in that directory? You will not be able to expand it, unless you are constantly monitoring the contents. Edscott However, just having the model change its mind turns out to be a very bad idea. I get messages like: (DirectoryTreeTest:30175): Gtk-CRITICAL **: file gtktreeview.c: line 3243 (gtk_tree_view_bin_expose): assertion `has_child' failed. There is a disparity between the internal view of the GtkTreeView, and the GtkTreeModel. This generally means that the model has changed without letting the view know. Any display from now on is likely to be incorrect. all over the place... How can I let the view know that the model has changed, and is it safe to do it from within the GtkTreeModel implementation? Cheers, -- Christer Palm ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: problem with g_locale_to_utf8()
On Fri, 2003-08-29 at 12:28, Paulo Ricardo Batista Mesquita wrote:
Hello guys,
I am writing an application that receives data in portuguese language, it runs both
Linux (English) and Windows (Brazilian Portuguese).
In the beginning, I was writing the code using non English characters, especially
when using message boxes. That time, it was working fine.
When I started to accentuate the words, I got some errors messages telling me that
PANGO don't accept non UTF-8 characters. Since then, I started to use
g_locale_to_utf8() function.
When running my application in Windows, it works fine. But, when I tested in Linux,
in the message boxes where I am using this function, the text doens't appears, just
appears an empty space (I think).
I am researching for an explanation to this, but I didn't get it yet. May someone
give me a help?
This utf business is a little tricky. For example, if you use
g_locale_to_utf8 but your locale is not set right (not uncommon) the
function won't work as you expect since it will not obtain a valide
codeset to do the translation. Here is a small wrapper program I use you
might find handy. The locale-defined codeset can be overridden by the
environment variable SMB_CODESET:
gchar *my_utf_string(char *t)
{
static gchar *s = NULL;
GError *error = NULL;
gsize r_bytes, w_bytes;
unsigned char *c;
const char *fc;
gchar *from_codeset=NULL;
if(!t) g_assert_not_reached();
if (g_utf8_validate (t,-1,NULL)) return t;
/* so we got a non-UTF-8 */
if (getenv(SMB_CODESET) strlen( getenv(SMB_CODESET))){
from_codeset=g_strdup(getenv(SMB_CODESET));
}
else {
g_get_charset(fc);
if (fc) from_codeset = g_strdup(fc);
else from_codeset = g_strdup(ISO-8859-1);
}
if (!strcmp(from_codeset,ISO-)){
g_free(from_codeset);
from_codeset = g_strdup(ISO-8859-1);
}
if(s) g_free(s);
for(c = (unsigned char *)t; *c != 0; c++)
if(*c 32 *c != '\n')
*c = ' ';
s = g_convert (t,strlen(t),UTF-8,from_codeset,r_bytes, w_bytes,
error);
g_free(from_codeset);
if(!s)
{
s=g_strdup(t);
for(c = s; *c != 0; c++) if(*c 128) *c = '?';
}
if(error){
printf(DBG: %s. Codeset for system is: %s\n,
error-message,from_codeset);
printf(DBG: You should set the environment variable SMB_CODESET
to ISO-8859-1\n);
g_error_free(error);
}
return s;
}
Edscott
Thanks,
Paulo Ricardo
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Changing [entire] background of a GtkTextView
On Sat, 2003-08-30 at 20:48, Vadim Berezniker wrote: Vadim Berezniker wrote: I want to change the entire background of a GtkTextView to the background of its parent container. Using Tags, I can only change the background of the parts of the view with text. Changing the background using the widget style has no effect. (The only thing that seems possible to change is the text color). (Basically, I'm trying to have a fancier label using a GtkTextView) Anybody? I have looked through the GTK code and still have not found a way. I really need this for a project I'm releasing soon. If you just want a fancier label, why don't you use a gtk_image and draw in the text? ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
toshiba-acpi-extras
Does anybody know if there are plans to port the toshiba-acpi-extras from linux to the freebsd kernel? Without these additional acpi variables it is not possible to adjust the LCD brightness for recent Toshiba laptops (satellite 2400,2450,2455 and others). Not being able to dim the LCD screen is a real bummer. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
incorrect keyboard response
I am installing FreeBSD on a new laptop but have problems with the keyboard within X. Symptoms: if the pause between stroking key1 and key2 is short, key1 is repeated. When: FreeBSD 5.1, always. FreeBSD 4.8, only when the XKEYBOARD extension is enabled. I've tried modifying the key repeat rate, both in X and on console, to no avail. The problem is not present in Linux or in older laptops. Laptop configuration: Toshiba [EMAIL PROTECTED], 533MHz system bus, nvidia-geoforce4-32MB. TIA Edscott Option XkbDisable is not set. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ehci in kernel
I have already done everything to make my usb keyboard work in FreeBSD (both 4.8 and 5.1) to no avail. It detects is correctly and sets it up as supposed to, but the show does not go on. In linux the usbkeyboard works but there is also a ehci controller loaded (ehci-hcd 00:1d.7: Intel Corp. 82801DB USB EHCI Controller). I took a shot in the dark and added optionsehci to the kernel configuration, but compilation bombs complaining about missing modules at the link stage. What else is needed to get the ehci controller to work? Or what is supposed to be done in this case? TIA Edscott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: glib 2.2.2 - g_tree
On vie, 2003-07-25 at 04:41, Albert Pala wrote: i want to ask if someone can help me: in my program at starup i create huge balanced tree ( ~3*10^6 items ) from fixed file. it took about 8s on my computer. how can i rearrange the input file to get shorter time ? ( minimize number of operation of balancing tree during inserts ) ? currently input file is sorted by key. You could try to write the file out as a DBHashTable which can do a balanced tree in a file. See http://dbh.sourceforge.net Edscott greetings albert. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Geting a GtkTreeModel out of GtkTreeViewColumn
El mar, 08-07-2003 a las 11:24, Andrej Prsa escribió:
Hello, everyone!
Could anyone please tell me if it's possible to extract the parent
GtkTreeModel out of GtkTreeViewColumn?
Or, if someone could maybe suggest a better way to extract the data from
the selected column in a function where GtkTreeViewColumn *column and int
row are arguments, e.g.
char *get_cell_contents (GtkTreeViewColumn *column, int row)
{
???
}
I would use g_object_set_data to associate the treemodel pointer with
the treeviewcolumn upon creation of the treeviewcolumn, and then use
g_object_get_data to retrieve the treemodel upon entering
*get_cell_contents(). Although this is based on the least effort
criteria, there is probably a simpler way (there always is).
Edscott
Thanks,
Andrej
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Trouble with GtkTreeModel co.
El vie, 04-07-2003 a las 11:38, Andrej Prsa escribió: Hi, everyone! I am trying to upgrade from CLists to GtkTreeViews since my transition from 1.2 to 2.0. I have a spin button that declares how many rows a GtkTreeModel (with a GtkListStore) should contain; attached to the changed signal for a spin-button I have a callback that should do this. While I worked with CLists, I simply used clist-rows to obtain the number of rows already present and compared this value to the value in a spin-button - thus knowing how to change the CList structure. So how do I do this with GtkTreeModel Co.? Specifically, how do I extract the number of rows already present? My suggestion would be to run a gtk_tree_model_foreach () on the treeview with a counter++, but there is probably a more clever solution. Edscott Thanks, Andrej ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Re[2]: Better accelerator keys support
El jue, 03-07-2003 a las 05:13, Martin Stubenschrott escribió:
Well, if the widget has the focus, then the space bar is natural.
Sorry, I think I didn't specify this clearly enough. I mean, when the
focus is on one button I can activate any other button with the
Alt-key support. Space bar only works if the widget has the focus, and
switching to one control out of dozens can be very time consuming.
What I meant, was that e.g. if the focus is on the button Sample
button I could activate the button Another button by just pressing
'A' instead of Alt-'A'. (On american keyboard this is not so annoying
since you have a second Alt-button right to the space bar, but on a
german keyboard layout, I don't have this second Alt button, which
means that I often need both hands to activate a shortcut).
The American keyboard has the same issue because the right-alt-key does
not generate the same modifier as the left.
This really made me wondering when I tried to switch to Linux since I
am a keyboard guy, and I always thougth linux was much better than
windows in this area, but actually I found out that Windows keyboard
accessibility support is even better than Linux's.
It's not windows, but the window's application you are talking about,
just as linux is far removed from a gtk application.
To get the thing you want bind the keypressed signal to all the buttons
where you want the behaviour described and write a small callback that
will generate a buttonclick signal depending on which letter was typed.
This here is an example where a keypress signal will do the effect of
pressing a button (without an accelerator being defined):
static gboolean treeview_key(GtkWidget *w,
GdkEventKey *event,gpointer data){
switch (event-keyval){
case GDK_Print:
tb_print((GtkButton *)w,NULL);
return TRUE;
case GDK_Execute:
on_run_activate((GtkMenuItem *)w, NULL);
return TRUE;
}
Look at gdk/gdkkeysyms.h
Edscott
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Better accelerator keys support
El lun, 30-06-2003 a las 14:54, Martin Stubenschrott escribió: Hi, I am not sure if this is acutally a GTK+ or Gnome thing, but there's is really one thing with keyboard accelerators which could be massively improved. In GTK+, if you have a button Test (sorry, i am/was only a windows developer, by putting the '' bevore the 'T' I meant that T was underlinded for quick access), you can use by pressing Alt-T. This is not bad, but Windows does this much better (and faster) I think. If the focus is on a button, checkbox or optionbutton, it is enough just to press T for selecting the button. The Alt key is only necessary if the focus is in an edit-field or listbox because than it is unclear if you want to write a T or select a button Test. This probably sounds very unimportant, but for an advanced keyboard user, it will speed things up extremely. I hope it is clear what I mean, and I am looking forward for your comments. Using the space bar to select the button (gtk default) is easy and natural. Even so, you can define a windowy behaviour by using the key-pressed signal on the widget. Edscott Best regards, Martin ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
checking for headers
Hi, I'm trying to get a configure program to check for dbh.h, but the following line only checks in /usr/include: AC_CHECK_HEADERS(dbh.h, ac_cv_dbh_library=yes, ac_cv_dbh_library=no) The generated configure in Linux searches both /usr/include and /usr/local/include, but not in FreeBSD. What do I have to add so that it will search /usr/local/include in FreeBSD? MTIA, Edscott Wilson Garcia To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
front end to pkg_xxx
I've been thinking about writing a gtk2 frontend for the pkg_ series of programs (pkg_add, pkg_create, pkg_delete, pkg_info, pkg_update, pkg_version) but maybe it's already been done. Has it been done before? Edscott Wilson Garcia To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
crash on gtk_tree_selection_get_selected
This one has me clueless and I don't know whether if it is a bug in
gtk2. I am porting xfsamba (frontend of the samba suite) to gtk2, and
when a server (represented by a row of a gtk_tree_view) is clicked on,
the program downloads information from the server (much like www
frontends). This is the code for the callback:
if (gtk_tree_selection_get_selected (selection, model, iter))
{
gtk_tree_model_get (GTK_TREE_MODEL (server_model), iter,
SERVER_NAME_COLUMN, sv, -1);
if (!sv || strlen(sv)==0){
print_status(_(Invalid server selected));
return;
}
strcpy(server,sv);
g_free (sv);
printf(got %s\n,server);
// crash:
SMBrefresh (server, RELOAD);
}
If I do not call the SMBrefresh routine, all's fine. If I call
SMBrefresh() from anywhere but here, all's fine. With gtk1.2 all's fine.
What troubles me is the traceback I get from the crash, since it does
not seem to be generated from xfsamba code but from gtk2 internals:
Program received signal SIGSEGV, Segmentation fault.
0x40118455 in gtk_range_get_value () from /usr/lib/libgtk-x11-2.0.so.0
(gdb) bt
#0 0x40118455 in gtk_range_get_value () from
/usr/lib/libgtk-x11-2.0.so.0
#1 0x401997b3 in gtk_tree_view_get_type () from
/usr/lib/libgtk-x11-2.0.so.0
#2 0x4019ebf7 in gtk_tree_view_set_reorderable ()
from /usr/lib/libgtk-x11-2.0.so.0
#3 0x40192362 in gtk_tree_view_get_type () from
/usr/lib/libgtk-x11-2.0.so.0
#4 0x400eff03 in gtk_propagate_event () from
/usr/lib/libgtk-x11-2.0.so.0
#5 0x4034a5c7 in g_type_class_meta_marshal ()
from /usr/lib/libgobject-2.0.so.0
#6 0x4034a17a in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#7 0x4035f436 in signal_emit_unlocked_R () from
/usr/lib/libgobject-2.0.so.0
#8 0x4035d751 in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#9 0x401294d5 in gtk_signal_emit () from /usr/lib/libgtk-x11-2.0.so.0
#10 0x401b0888 in gtk_widget_send_expose () from
/usr/lib/libgtk-x11-2.0.so.0
#11 0x400efda3 in gtk_propagate_event () from
/usr/lib/libgtk-x11-2.0.so.0
#12 0x400eebff in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x40272013 in gdk_add_client_message_filter ()
from /usr/lib/libgdk-x11-2.0.so.0
#14 0x403a1dd3 in g_main_dispatch () from /usr/lib/libglib-2.0.so.0
#15 0x403a2c51 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#16 0x403a3011 in g_main_context_iterate () from
/usr/lib/libglib-2.0.so.0
#17 0x403a3720 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#18 0x400ee2b3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#19 0x0804c487 in main (argc=1, argv=0xb9f4) at xfsamba.c:236
Would this be a bug in gtk2? (using RH gtk2-2.0.2-4).
Edscott Wilson Garcia
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
[Xpert]application crash: xfree4.2+xinerama
Hello, With xfree4.2 and xinerama, applications like lyx and xscreensaver crash with a unable to access private resource X message. They crash when opened on any screen. If I disable xinerama, They will work on screen 0, but still crash on screen 1 or screen 2. The configuration I have is screen0 0 0: Geoforce AGP 32 MB screen1 LeftOf screen0: Matrox milenium 2Mb screen2 LeftOf screen1: Matrox milenium 2Mb Everything worked fine until xfree4.2, installed with redhat 7.3. thank you, Edscott Wilson Garcia ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
fourth type of dnd
Hello, I would like to enable a fourth type of drag+drog in a filemanager program. The first three, GDK_ACTION_COPY , GDK_ACTION_MOVE , GDK_ACTION_LINK do exactly that and are generated by combining the d+d with ctl and ctl-shift. But there is also a GDK_ACTION_PRIVATE which I would like to use. Or maybe the GDK_ACTION_ASK. With what d+d keyboard combination could these be generated? Muchos thanks in advance for your time, Edscott Wilson Garcia ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Copying bitmaps into bitmaps
I've been trying to copy a bitmap into a bitmap with gdk_draw_pixmap(), without success. Is it necesary to use XCopyPlane in lieu of some gdk routine? Basically all I want to do is a binary OR between the data in the 2 bitmaps. TIA, Edscott Wilson Garcia ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Copying bitmaps into bitmaps
On Thu 17 Jan 2002 10:01, Havoc Pennington wrote: Edscott Wilson García [EMAIL PROTECTED] writes: I've been trying to copy a bitmap into a bitmap with gdk_draw_pixmap(), without success. Is it necesary to use XCopyPlane in lieu of some gdk routine? When you say without success, what happens? It should work fine. I get messages like: xftree: Fatal XLib internal error BadMatch (invalid parameter attributes) Request 62, Error 8 when I try to use the resulting bitmap. It croaks with only one copy from existing bitmap to a bitmap created with gdk_pixmap_new(window,pix_w,pix_h,1). After looking at a book by Barkakati, (X Window System Programming, 1991) he says that bitmaps should be copied into pixmaps by XCopyPlane(), not XCopyArea() (the latter being used by gdk_draw_pixmap()). Basically all I want to do is a binary OR between the data in the 2 bitmaps. That isn't what gdk_draw_pixmap() normally does, it just copies the bits and overwrites the ones in dest. Look at gdk_gc_set_function(), I'm not sure it affects drawing a pixmap but I think it might. Basically what I want is a transparency mask resulting from the combination of two (or more) pixmaps with different transparency masks. Which would be a binary AND between the data. I'll look at gdk_gc_set_function(), and see what I can do with it. saludos, Edscott Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
