Lex, I think "execute" is broken in this nightly build 22 February. Python programs are not running as well.
Noli On 2/23/10, Noli Sicad <[email protected]> wrote: > Hi Lex, > > I download the geany nightly build windows and I can see that there is > new built setting. And there is new menu item - Set Build Commands and > dialog box. It is not useful to what I need -). > > The new geany is really nice looking in this build. It seems that it > has gtk theme now. > > Anyway, I tried to implement what you suggested. > > In .filetype_extensions.conf > glpk = *.mod > > In filetypes.glpk > run_cmd=c:\glpsol -m "%f" > > It is not working. > > I tried this > > run_cmd=c:\\glpsol -m "%f" > > I tried this > run_cmd=c:/glpsol -m "%f" > > I tried this as well. > run_cmd=c://glpsol -m "%f" > > I got this error / result > > '.' is not recognized as an internal or external command, > operable program or batch file. > Press any key to continue . . . > > It is not working! > > Vellam 22 Feb build > > Regards, Noli > > > On 2/23/10, Lex Trotman <[email protected]> wrote: >> On 23 February 2010 18:18, Noli Sicad <[email protected]> wrote: >> >>> Hi Lex, >>> >>> Thanks you for taking the time in answering my question. >>> >>> > I'm not sure that my point was clear enough. >>> >>> I think your point is clear enough. >>> >>> > Geany has a unified model of a file type. When a file is loaded, its >>> type >>> > is determined (or it is set by Document->Set Filetype ->...). This >>> > type >>> > controls the text highlighting and the filetype dependent build menu >>> > commands. >>> >>> Probably if GLPK is created in the 50's the address the needs of the >>> time, then there is no problem, it would a fit into the mold classic >>> c/c++ compiler. >>> >>> compiler = glpsol --mps mylinearprogramingmodel.mps >>> run_cmd = glpsol -mps mylinearprogrammingmodle.mps. >>> >>> BTW, the MPS is created by IBM in the 50. MPS is mathmatical >>> programming system >>> >>> On line doc >>> http://projects.gnome.org/gnumeric/doc/file-format-mps.shtml >>> >>> Then followed by the LP format >>> LP format doc >>> http://www.gurobi.com/html/doc/refman/node386.html >>> >>> >>> > Scite (and apparently TextAdept) does not have a unified model, the >>> commands >>> > have to be specified separately by extension as your post showed. I >>> > am >>> not >>> > saying one model is better than another, they are just different. In >>> this >>> > case Scite can be more flexible, but the Geany model has other >>> > advantages >>> > and AFAIK this is the first time this problem has occurred. >>> >>> As I mentioned, SciTE is the father of all scintilla base editors. >>> Since the developer of TextAdept is author of SciTE cloned >>> (SciTe-tools - scintilla lua dynamic lexer). He knows exactly why >>> SciTE has 56 languages and scripts and does not fit into "unified >>> model", the classic c compier, I suppose. >>> >> >> Actually the C compiler is the one that is most likely to require >> different >> handling of .h and .c files if your compiler produces pre-compiled >> headers. >> So the "traditional" is not the best example but I know what you mean :-) >> >> >>> >>> > I am about to start more changes to the Geany build system that will >>> further >>> > improve its flexibility. But providing separate commands for >>> > different >>> > extensions within a single filetype is not in the plan because as I >>> > said, >>> > its never been needed before. Without that capability Glpk can still >>> > be >>> > supported in two ways: >>> >>> > 1. each of the extensions is a separate filetype, but using the same >>> > highlighting (BTW what lexer do you use with Scite because AFAIK it >>> doesn't >>> > support GLPK) this is supported now in SVN with custom filetypes >>> >>> The problem is we will have 5 (mps, lp(cplex), fps(freemps), >>> mod(mathprog), glp(glpk)) separates filetypes. What name should we use >>> ? Probably, glpk_mps, glpk_lp, glpk_fmps, glpk_mathprog, and glpk_glp, >>> it might work but messy. Aside from this, glpsol has ability to >>> translate/convert one format to another. Most of the solvers use mps >>> format. GLPK is one of the best in the area and this is the reason why >>> I am promoting GLPK to the Geany users. >>> >> >> I know its messy but it is available NOW. All other options require >> development and will therefore take time. >> >> >>> >>> In GUSEK IDE, we use, c, sql and asm lexers to create the >>> glmp.properties. >>> >>> In TextAdept, I adopted c lexer and modified it to create glpk.lua >>> lexer. TextAdept use the lua dynamic lexer loading. >>> >>> >> Oh, Ok you have your own lexer, which you would need to add to Geany >> anyway. >> >> >>> > 2. a plugin is added which modifies the command for GLPK files >>> > depending >>> on >>> > the extension, this requires the re-make to be available (and the >>> > plugin >>> to >>> > be written) but might be considered to be cleaner >>> >>> I think this is the best option. >>> >>> > To use method 1 all you need to do is to copy your current filetypes >>> > file >>> so >>> > you have one per extension, set the compile (or whatever) command in >>> > the >>> > [build-menu] section for each, and edit filetype_extensions.conf to >>> > reference them. >>> >>> I think this is the hack (method 1) and probably use just use - glpk1, >>> glpk2, glpk3, glpk4, glpk5 >>> >>> I hope Geany developers that address this issue. >>> >>> Right now, windows users can use GUSEK IDE and TextAdept, for Mac OS X >>> users TextAdept and for linux users TextAdept and classic editors. >>> >> >> >> As I said option 1 its a way of using Geany until alternative means is >> supported, or use these alternatives instead. >> >> Cheers >> Lex >> >> >> >>> >>> Lex, thanks again. >>> >>> Regards, Noli >>> _______________________________________________ >>> Geany-devel mailing list >>> [email protected] >>> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel >>> >> > _______________________________________________ Geany-devel mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
