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(&parm); int retval = glp_simplex(lp, &parm); 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
Re: Endorsement of the GNU Social Contract
, and aims to extend the reach of the project beyond > the GNU System. > > > ## The GNU Project welcomes contributions from all and everyone > > The GNU Project commits to providing a harassment-free > experience for all contributors. It wants to give everyone the > opportunity of contributing to its efforts on any of the many tasks that > require work. It welcomes all contributors, regardless of their gender, > ethnicity, sexual orientation, level of experience, or any other > personal characteristics. > > -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute
[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&utm_medium=cpm&utm_content=mail_header&utm_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 > >
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=...
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_MGC
[DuMuX] Please excuse multiple posts
I'm sorry for sending multiple posts, but it seems that the list server may be ignoring the settings for sending me back my list postings. Best regards Edscott ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
[DuMuX] memory corruption in brookscorey.hh?
une/lib64/libdunegeometry.a /opt/dune/lib64/libdunecommon.a -pthread -lpsurface -lmetis -lm -lz -Wl,-Bstatic -lVc -Wl,-Bdynamic -lgmp -lgmpxx /usr/lib/openmpi/libmpi.so -llapack -lblas Any pointer would be greatly appreciated. kind 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] 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 : > > > 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 >
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 : > 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 on
Re: [DuMuX] DuMux and Docker
Thanks for the information, Timo. I'll look into it as soon as possible. The docker containers we are using are available at the docker hub at the repository impmx/lswf, I will see on updating them with the methods in the DuMux containers you mention. I am more than happy to contribute whatever comes of this to the DuMux community. As soon as I have something new I will let you know. Best regards Edscott El 03/01/2018 10:47 a.m., "Timo Koch" escribió: 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 on Linux machines. * DuMux also uses Docker for automated testing with buildbot ( https://git.iws.uni-stuttgart.de/buildbot/#/builders). * There is a DockerHub group for DuMux (https://hub.docker.com/u/dumux/), however it's also a bit outdated. If you are interested in contributing useful Docker images, we are happy, please contact us. Best wishes, Timo On 03.01.2018 17:26, Edscott Wilson wrote: I'll chip in my feedback from a DuMux user's viewpoint. To create DuMux problems with dune, basic generic C++ programming is a must, so updating a particular compilation requirement either from source or from binary distribution library should not pose a problem. But what if it is a problem? In our workgroup we use an ArchLinux based docker container prepared with all the necessary compilation tools. Why ArchLinux based? Because it is a rolling release targeted at users who will be compiling programs. This differs from Linux distributions targeted at non compiling users (debian/redhat/opensuse and variants) where library headers are separated into different packages. This makes updating the docker container rather simple and always up to date. Users in the non developer Linux distributions can run dune problems without any need for any compilation tools (just needs docker). But what about performance in the docker container? We have run our DuMux problem on a Linux box using mpi with 8 processes, both in and out of a docker container. The performance is almost the same.This is quite different from a virtualbox Linux client on a more robust windows host, where performance is degraded by at least 40 percent. So docker is a perfect solution? Not yet. The main issue is the absence of a graphical environment. This means that file editing and result analysis must be done in the host computer. Moving files to-and-from the host to the container is tedious and not very efficient. A solution would be an environment where the docker container inputs and outputs directly to the host computer disk space with some kind of python script do process commands from the host and communicate with the docker container. We have not done that yet, but it sounds like fun. In conclusion, from a simple user's viewpoint, upgrading to cmake 3.1 and gcc 7 is just fine. best regards, Edscott El 03/01/2018 8:47 a.m., "Steffen Müthing" escribió: > > > Am 03.01.2018 um 15:43 schrieb Christian Engwer < > christian.eng...@uni-muenster.de>: > > > >> OTOH, CMake 2.8 in particular has a whole bunch of weird little bugs > and subtle > >> differences from CMake >= 3.1 (not accepting keyword arguments in some > places where > >> later releases will flag a deprecation warning if you leave them away > for example). And configuring > >> different modules at different compatibility levels is just an > invitation for horrible small problems, mostly > >> because our downstream modules all re-run the CMake code of upstream > modules. > > > > Sorry, but this means the whole buildsystem is broken. The implication > > of what you just said is, that we have to use the most recent cmake, > > as some downstream module might use it. > > > > I'm happy bumping hte requirements, if there is a particular reason, > > but not just some vague "little bugs and subtle differences". That > > cmake is strange is a problem for a long time and it will be like this > > also for an other long time. I there is a particular bug we fixed and > > thus had to raise the r
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 : > 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
whenever you give out the URL 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=www&content-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 > 于 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=119420431&iu=/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=119420431&iu=/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 > 于 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.7z&can=1&q=#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.7z&can=2&q=#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=119420431&iu=/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=119420431&iu=/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 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 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 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=84349351&iu=/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=84349351&iu=/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
// Timeout has expired. +if (sem_trywait(sem) < 0){ +// Cannot immediately decrease semaphore +errno = EAGAIN; +return -1; +} +// Semaphore immediately decreased. +return 0; +} -int -sem_getvalue (sem_t *sem, int *sval) -{ - _sem_t *sv; - int r; - if (!sval) -return sem_result (EINVAL); - - if (!sem || (sv = *sem) == NULL) -return sem_result (EINVAL); - - if ((r = pthread_mutex_lock (&sv->vlock)) != 0) -return sem_result (r); - if (*sem == NULL) -{ - pthread_mutex_unlock (&sv->vlock); - return sem_result (EINVAL); -} - - *sval = (int) sv->value; - pthread_mutex_unlock (&sv->vlock); - return 0; +// Note: Seems this can't be implemented in Windows. +int sem_getvalue(sem_t * sem, int * sval){ +errno = EINVAL; +DBG( "sem_getvalue(): %s\n", strerror(errno)); +return -1; } Index: mingw-w64-libraries/winpthreads/src/sem.h === --- 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 -#include "mutex.h" +# include +# include +# include +# include +# include +# include -#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=63431311&iu=/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 > > > 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=63469471&iu=/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 > -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=63469471&iu=/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=63469471&iu=/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 #include # 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(
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 > 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
Re: [Mingw-w64-public] semaphore wrappers
2013/11/9 dw >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 > page<http://man7.org/linux/man-pages/man3/sem_wait.3.html>I 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=60136231&iu=/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
Here's some code to enable named semaphores as defined in . 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 #include # 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=60136231&iu=/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 > -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=60136231&iu=/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=60136231&iu=/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
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). Next step would be to resort to CreateSemaphore from the winAPI and see if I can wrap it around the missing implementation. I'll let you all know how that fares... BTW, in the old MinGW(.org) toolchain, the program will simply not compile (error: 'SEM_FAILED' undeclared). 2013/11/6 Ruben Van Boxem > 2013/11/6 niXman > >> Ruben Van Boxem писал 2013-11-05 23:57: >> >> > 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 >> >> Previously I reported about that the MinGW-builds project will no longer >> be updated, as we have joined MinGW-W64 project. >> > > My bad, I thought I copied them from the right place. Guess I didn't look > well enough :-/ > > Ruben > > >> You can get builds here: >> i686: >> >> https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/ >> x86_64<https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/x86_64> >> : >> >> https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/ >> >> >> -- >> Regards, niXman >> ___ >> Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: >> http://sourceforge.net/projects/mingw-w64/ >> ___ >> Another online IDE: http://liveworkspace.org/ >> >> >> -- >> 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=60136231&iu=/4140/ostg.clktrk >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > > > > -- > 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=60136231&iu=/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=60136231&iu=/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 > > > 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=60136231&iu=/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
ompile, then program will crash in Windows, and in Windows only. This is the example crash giving the program the "ls" command to execute: --- 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=60136231&iu=/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 > > > 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=65839951&iu=/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 and link with -lpthread. Windows semaphores are defined in . 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 > Hi Edscott, > > thanks for testing this. I just have one small question about one > paragraph. > > 2013/11/4 Edscott Wilson : > > 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=65839951&iu=/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=65839951&iu=/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 > > > > 2013/10/21 LRN > >> 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=65839951&iu=/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
Re: [Mingw-w64-public] Shared semaphores
2013/10/21 LRN > 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 -- 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=60135031&iu=/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] 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=60135031&iu=/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=60135031&iu=/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 > Thanks everyone. > > *From:* Incongruous > *Sent:* Tuesday, October 15, 2013 6:06 AM > *To:* MinGW-64 Mailinglist > *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=60135031&iu=/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=60135031&iu=/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=60135031&iu=/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 > On 10/16/13, Edscott Wilson wrote: > > 2013/10/16 Ruben Van Boxem > > > >> 2013/10/16 Edscott Wilson > >> > >>> > >>> 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=60135031&iu=/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=60135031&iu=/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 > 2013/10/16 Edscott Wilson > >> >> 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=60135031&iu=/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
Problem with fseek is: int fseek(FILE *stream, long offset, int whence); While lseek: off_t lseek(int fd, off_t offset, int whence); On 32 bit systems, fseek is limited to 2 GB. Usage of lseek allows for use of off_t, which with mingw-64, will be 64 bit and allow for files > 2 GB. 2013/10/16 niXman > ** > > Edscott Wilson писал 2013-10-16 18:53: > > ... Since I require use of lseek() ... > > man fseek > > > -- > Regards, niXman > ___ > Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit > Windows:http://sourceforge.net/projects/mingw-w64/ > ___ > Another online IDE: http://liveworkspace.org/ > > > > -- > 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=60135031&iu=/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=60135031&iu=/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=60135031&iu=/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 #include #include #include #include #include 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=60135031&iu=/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 > Only confirmed! Managed to solve your problem? > > Só confirmando! Conseguiu resolver seu problema? > --- > > > 2013/9/3 Edscott Wilson > >> Thank you! I will try your suggestion. >> >> >> 2013/9/2 Alcione Ferreira >> >>> >>> -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 >>> . >>> Segue o techo que usei para testar: >>> #if defined(__WIN32__) || defined(__WIN__) >>> #include >>> #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 . >>> Follows the techo I used to test: >>> # if defined (__WIN32__) | | defined (__WIN__) >>> # include >>> # 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@g
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
his 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
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
2013/3/26 Allin Cottrell > 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
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 > 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.
Re: Confused about GDKPixBuf/Cairo interaction
2013/2/18 Colomban Wendling > > 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
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 > > 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_VERSION<3 > 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) >
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_VERSION<3 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 pse3
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 > 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 > >> 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?)
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 > 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 > 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?
2013/1/23 David Nečas > > 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
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 > > 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
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 > 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 Software Dayton, 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 \ > > > @@
[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 > 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 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: [Thunar-dev] Thunar-dev Digest, Vol 7, Issue 12
El vie, 26-08-2005 a las 12:00 +, [EMAIL PROTECTED] escribió: > Send Thunar-dev mailing list submissions to > thunar-dev@xfce.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://foo-projects.org/mailman/listinfo/thunar-dev > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Thunar-dev digest..." > > > Today's Topics: > >1. Mime Recognition (Ori Bernstein) >2. Re: Mime Recognition (Benedikt Meurer) >3. Re: Mime Recognition (Benedikt Meurer) >4. Re: Mime Recognition (Ori Bernstein) >5. Re: Mime Recognition (Benedikt Meurer) > > > -- > > Message: 1 > Date: Thu, 25 Aug 2005 17:30:28 -0400 > From: Ori Bernstein <[EMAIL PROTECTED]> > Subject: [Thunar-dev] Mime Recognition > To: thunar-dev@xfce.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII > > >From what I've seen of the Thunar source code, it looks like all the mime > recognition resides in thunar-vfs/thunar-vfs-mime*. > > What I'd like to propose is moving this mime parsing code out into either > libexo or libxfce4util, allowing other programs to use this mime database > code. > > I think that this will make it much easier to implement properly opening files > in programs like email clients, which have to recognize attachments and find > out program associations, or panel launchers, which would be able to accept a > file URI instead of a command line, and also be able to decide on the icon to > display automatically. > > I'm sure that there are many other examples of programs throughout the desktop > that would be able to generic mime information to their advantage. > > Does anyone agree that putting mime parsing in a library available to any Xfce > application is a good idea? or am I off my rocker? > > You currently (xfce-4.2.x) can also have mime recognition by loading the "mime" module installed by libxfcegui4. You do not have to link with this module, instead load as a plugin. Apparently the gtk doc generation is borked so you also have to look for the comments in source (placed in .h file). -- Edscott Wilson Garcia <[EMAIL PROTECTED]> ___ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev
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: 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
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: 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
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
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: 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
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: 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
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: 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
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: Treeview help needed
On Sun, 2003-08-17 at 23:33, Vadim Berezniker wrote: > wilfried kopp wrote: > > Hi everybody, > > > > I am stuck with a segmentation fault caused by a treeview and I have pent hours > > trying to figure out what's wrong with no success. > > > > > > Here is how I create the model (I simplified the code... but this version crashes > > as well...) > > while (item) > > { > > gtk_list_store_append (store, &iter); > > gtk_list_store_set (store, &iter, > > MIME_TYPES_TO_SKIP_COLUMN_STATE, 0 , > > MIME_TYPES_TO_SKIP_COLUMN_MIME_TYPE, test, > > -1); > > > > item=g_list_next(item); > > } > > > > That looks OK. > > > The segmentation fault happens when I remove an item with this code: > > gtk_tree_model_get (model,&iter, > > 0, &state, > > 1, &mime_type, > > -1); > > > > Why are you using constants such as (MIME_TYPES_TO_SKIP_COLUMN_STATE and > MIME_TYPES_TO_SKIP_COLUMN_MIME_TYPE) in the code that adds data but > referencing them by number here. This could lead to problems if the > constants change later. > > > if (gtk_tree_selection_get_selected (listSelection, NULL, &iter)) > > { > > gtk_list_store_remove (GTK_LIST_STORE (model), &iter); > > } > > > > > > Here is what ddd says: > > (gtktalog:5396): Gtk-CRITICAL **: file ../../gtk/gtkliststore.c: line 566 > > (gtk_list_store_get_value): assertion `GTK_LIST_STORE (tree_model)->stamp == > > iter->stamp' failed > > > > The error seems to indicate that you modified the model after retrieving > the iterator, which invalidates the iterator. To avoid this, use a GtkTreeRowReference to recalculate a valid iterator. > > ___ > 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]"
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]"
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]"
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 Edscott > ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list