From: Bogdan <lov...@ya...> - 2012-07-20 07:46:11
|
Hi, The MinGW "installer" for Octave is actually an archive containing MSYS and also a lot of unnecessary items. Wouldn't it make more sense to only distribute the binaries and instruct people to install MSYS and put them there? Some of us already have MSYS installed. Cheers, Bogdan |
From: Philip N. <pr....@hc...> - 2012-07-20 09:18:38
|
Hello Bogdan: Bogdan wrote: > Hi, > > The MinGW "installer" for Octave is actually an archive containing MSYS > and also a lot of unnecessary items. Wouldn't it make more sense to only > distribute the binaries and instruct people to install MSYS and put them > there? Some of us already have MSYS installed. Here: ^^^^^^^^^^ you wrote down your own answer. "some of us"; well the vast majority of Octave users on Windows didn't have MSYS installed beforehand. So for them this is a vital part of the installer archive. Admittedly there's some overhead inside. What's the problem with that? On this box I have a complete MinGW/MSYS development environment installed, plus 5 or 6 Octave-MinGW versions including MSYS + a lot more. It takes up a bit of disk space, true, but these days that shouldn't be a problem. All those MinGW/MSYS environments are not in each others way. I have run MinGW-Octave versions from 3.2.4 to 3.6.2 simultaneously w/o problems. The implications of your suggestion are that candidate Octave users, most of which are probably non-developers, should install MinGW, + MSYS, + Octave dependencies, + Octave, + gnuwin32, + gnuplot, + etc. etc. And with a next Octave version, which might be based on newer build tools, they may need to upgrade to newer MinGW/MSYS versions plus the rest as well. Now, the whole point of the MinGW-Octave installers was to make getting Octave as easy as possible for people who are only interested in Octave itself, rather than in the stuff it was based on. If you could compare the total number of Octave-MinGW installer downloads versus the number of pure MinGW/MSYS downloads you'd understand why this strategy has been so successful. BTW The MSVC version also contains MSYS. Philip |
From: Andy B. <and...@gm...> - 2012-07-20 09:28:32
|
On 20 July 2012 10:18, Philip Nienhuis <pr....@hc...> wrote: > Hello Bogdan: > > Bogdan wrote: > > Hi, > > > > The MinGW "installer" for Octave is actually an archive containing MSYS > > and also a lot of unnecessary items. Wouldn't it make more sense to only > > distribute the binaries and instruct people to install MSYS and put them > > there? Some of us already have MSYS installed. > > Here: ^^^^^^^^^^ you wrote down your own answer. > "some of us"; well the vast majority of Octave users on Windows didn't > have MSYS installed beforehand. So for them this is a vital part of the > installer archive. > > Admittedly there's some overhead inside. What's the problem with that? > > On this box I have a complete MinGW/MSYS development environment > installed, plus 5 or 6 Octave-MinGW versions including MSYS + a lot > more. It takes up a bit of disk space, true, but these days that > shouldn't be a problem. > All those MinGW/MSYS environments are not in each others way. I have run > MinGW-Octave versions from 3.2.4 to 3.6.2 simultaneously w/o problems. > > The implications of your suggestion are that candidate Octave users, > most of which are probably non-developers, should install MinGW, + MSYS, > + Octave dependencies, + Octave, + gnuwin32, + gnuplot, + etc. etc. And > with a next Octave version, which might be based on newer build tools, > they may need to upgrade to newer MinGW/MSYS versions plus the rest as > well. > > Now, the whole point of the MinGW-Octave installers was to make getting > Octave as easy as possible for people who are only interested in Octave > itself, rather than in the stuff it was based on. > If you could compare the total number of Octave-MinGW installer > downloads versus the number of pure MinGW/MSYS downloads you'd > understand why this strategy has been so successful. > > BTW The MSVC version also contains MSYS. > > Philip > I agree with Philip it is probably more convenient for most to have everything packaged together. I agree with Bogdan that an archive file is not an installer, but don't think it matters much. Bogdan - if you would like to contribute an alternative package that does not have MSYS, feel free. We can then see which packages are downloaded more. -- /* andy buckle */ |
From: Michael G. <mic...@gm...> - 2012-07-20 09:31:05
|
On Fri, Jul 20, 2012 at 10:18 AM, Philip Nienhuis <pr....@hc...>wrote: > Hello Bogdan: > > Bogdan wrote: > > Hi, > > > > The MinGW "installer" for Octave is actually an archive containing MSYS > > and also a lot of unnecessary items. Wouldn't it make more sense to only > > distribute the binaries and instruct people to install MSYS and put them > > there? Some of us already have MSYS installed. > > Here: ^^^^^^^^^^ you wrote down your own answer. > "some of us"; well the vast majority of Octave users on Windows didn't > have MSYS installed beforehand. So for them this is a vital part of the > installer archive. > > Admittedly there's some overhead inside. What's the problem with that? > > On this box I have a complete MinGW/MSYS development environment > installed, plus 5 or 6 Octave-MinGW versions including MSYS + a lot > more. It takes up a bit of disk space, true, but these days that > shouldn't be a problem. > All those MinGW/MSYS environments are not in each others way. I have run > MinGW-Octave versions from 3.2.4 to 3.6.2 simultaneously w/o problems. > > The implications of your suggestion are that candidate Octave users, > most of which are probably non-developers, should install MinGW, + MSYS, > + Octave dependencies, + Octave, + gnuwin32, + gnuplot, + etc. etc. And > with a next Octave version, which might be based on newer build tools, > they may need to upgrade to newer MinGW/MSYS versions plus the rest as > well. > > Now, the whole point of the MinGW-Octave installers was to make getting > Octave as easy as possible for people who are only interested in Octave > itself, rather than in the stuff it was based on. > If you could compare the total number of Octave-MinGW installer > downloads versus the number of pure MinGW/MSYS downloads you'd > understand why this strategy has been so successful. > > BTW The MSVC version also contains MSYS. > It's optional and can be deselected at installation time. MSYS is really only used to provide support for the "pkg" system, which requires a shell. If you already have MSYS available, you can use it instead. Michael. |
From: Thomas W. <tw...@de...> - 2012-07-20 13:39:09
|
On Fri, Jul 20, 2012 at 11:18:35AM +0200, Philip Nienhuis wrote: > Admittedly there's some overhead inside. What's the problem with that? > > On this box I have a complete MinGW/MSYS development environment > installed, plus 5 or 6 Octave-MinGW versions including MSYS + a lot > more. It takes up a bit of disk space, true, but these days that > shouldn't be a problem. I suggest you take a moment and take SF's perspective. >From their website, they say that they have had 4 millions downloads *today*. Let's pretend that just 1% of those downloads included msys, which has about 3 MB according to http://sourceforge.net/projects/mingw/files/MSYS/Base/msys-core/msys-1.0.11/ That's 120 GB of network traffic on one(!) day just for MSYS. If you were to distribute this via Amazon's S3 (0.12$/GB)[1], that's roughly 12$/day. At the end of a year, that's 4000$ - again, just for MSYS. FWIW, one of the reasons for dropping the m68k architecture from Debian was the fact that a full Debian mirror exceeded 100GB in harddisk space and most mirror operators could not justify that much space. Now, the numbers may vary (especially the 1% above is probably too high), but then again we have only talked about msys and nothing else. So please, don't take your local hard disk as reference for what forms a problem in software distribution. [1] http://aws.amazon.com/de/s3/pricing/ Thomas |
From: Philip N. <pr....@hc...> - 2012-07-20 17:13:03
|
Thomas Weber wrote: > On Fri, Jul 20, 2012 at 11:18:35AM +0200, Philip Nienhuis wrote: >> Admittedly there's some overhead inside. What's the problem with that? >> >> On this box I have a complete MinGW/MSYS development environment >> installed, plus 5 or 6 Octave-MinGW versions including MSYS + a lot >> more. It takes up a bit of disk space, true, but these days that >> shouldn't be a problem. > > I suggest you take a moment and take SF's perspective. >> From their website, they say that they have had 4 millions downloads > *today*. Let's pretend that just 1% of those downloads included msys, > which has about 3 MB according to > http://sourceforge.net/projects/mingw/files/MSYS/Base/msys-core/msys-1.0.11/ > > That's 120 GB of network traffic on one(!) day just for MSYS. > > If you were to distribute this via Amazon's S3 (0.12$/GB)[1], that's > roughly 12$/day. At the end of a year, that's 4000$ - again, just for MSYS. > > FWIW, one of the reasons for dropping the m68k architecture from Debian > was the fact that a full Debian mirror exceeded 100GB in harddisk space > and most mirror operators could not justify that much space. > > Now, the numbers may vary (especially the 1% above is probably too > high), but then again we have only talked about msys and nothing else. > So please, don't take your local hard disk as reference for what forms a > problem in software distribution. > > [1] http://aws.amazon.com/de/s3/pricing/ Thanks Thomas for an enlightening post. Indeed, there are more perspectives and interests than just Octave users, developers etc. But I have ambiguous feelings on this subject. While I can easily perceive that for a single project based on volunteers like Debian the distribution costs issue is very real, I think the SourceForge case is a bit different. Just expanding on your figures: IIRC Octave-MinGW_3.2.4 had around 1 million downloads in total. I can't dig up those for the later MinGW-installers (it looks like the numbers have been reset, perhaps by shuffling around files), but AFAICR they hovered around some tens of thousands. Just assume that all MinGW installers together had 1.5 million d/lds. Imagining a rough average size of Octave's MinGW binaries of 150 MB, download costs of all MinGW binaries from SF in history, at $0.12/GB, would amount to some $27,000 (IMO still an inflated guess). Perhaps I'm spoiled, but <shrug> - I'm not so impressed by that figure. I can't imagine that Sourceforge, whose core biz *is* SW distribution, doesn't have a business model that let them cope with this at ease. If they couldn't they would already have signaled this to the OF site maintainers a long time ago. Until then it simply isn't our problem. More to the point: as long as SF doesn't complain, we shouldn't need to worry too much. Nevertheless I think it is *very* good that you draw attention to some hidden, less favorable and especially, non-durable aspects of "free" software. It would be nice to have an incremental mode for distribution of (Windows) installers to conserve bandwidth. But it should be easy enough to keep on attracting non-devs (if even n00bs) to download Octave. The MSVC version already comes this way, at the cost of another scarce resource (= the packager's (Michael's) time). So I guess my POV is this: If the choice is between * Ease of installation for novice users, implying less frustration with them and better reputation for Octave, and less installation support time for the devs around here, -versus- * Avoiding hidden distribution costs that we yet haven't heard about anyway, I'd simply prefer the former. But admittedly there's a slight itchy feeling. Philip |
From: Bogdan <lov...@ya...> - 2012-07-21 05:36:16
|
Hi, There is an alternative, of course. The MinGW folks have had an installer for some time, mingw-get (and a graphical version of it, which is WIP). This can install, handle dependencies, uninstall, update, etc. packages; everything from MSYS to GCC and bzip2 is distributed in this fashion---which is part of the reason why it may seem that there aren't too many MinGW installer downloads. Basically, it can do everything that is expected of a package manager. How about providing such a package for Octave? The package consists of an XML catalogue and one or more archives for different components of the package (e.g., one may wish to separate documentation, binaries, license stuff, extra stuff, etc.). This seems like the perfect solution. Cheers, Bogdan |
From: Philip N. <pr....@hc...> - 2012-07-21 09:10:46
|
Hi Bogdan, <Oct-Dev ML added in TO: list. Pls do "reply all" when answering> Bogdan wrote: > Hi, > > There is an alternative, of course. The MinGW folks have had an > installer for some time, mingw-get (and a graphical version of it, which > is WIP). This can install, handle dependencies, uninstall, update, etc. > packages; everything from MSYS to GCC and bzip2 is distributed in this > fashion---which is part of the reason why it may seem that there aren't > too many MinGW installer downloads. Basically, it can do everything that > is expected of a package manager. There's a precedent: Cygwin. As far as Octave-on-Windows goes, Cygwin has never been as successful as the complete "archive installers" and NSIS installers. Why would MinGW-get perform better? > How about providing such a package for Octave? The package consists of > an XML catalogue and one or more archives for different components of > the package (e.g., one may wish to separate documentation, binaries, > license stuff, extra stuff, etc.). This seems like the perfect solution. Of course the usual insipid answer: It's up to you. This is a volunteer project, remember. Please go ahead. To have a start: All dependencies for core Octave have been built by Tatsuro Matsuoka based on a.o., gcc4.6.2 and can be found here, together with build instructions: http://www.tatsuromatsuoka.com/octave/Eng/Win/ Then, Nitzan compiled and built later Octave version binaries, + built almost all Octave Forge packages. AFAIK he patched & amended a few things but unfortunately he never clearly outlined those fixes. (That is, Nitzan and I use Tatsuro's build stuff but N. gets better test results. And he can build much more OF packages than me.) <SKEPTIC MODE on> But even if you proceed this way (which we all would applaud I think), the points in my previous e-mail still apply: 1. Focus (Barring download limits on SourceForge) Please consider balancing precious developer time for core Octave and Octave-Forge development, versus investing precious developer time for building a package mgmt system from scratch and maintaining it. The weak point here has always been lack of developers for Windows. We are very lucky at the moment to have about 2-3 names "active", incl. the one building the MSVC binaries. 2. User perception (The main point with Octave on Windows) Rare exceptions aside, the intended audience isn't known for patience with and insight in pkg management systems (see Cygwin). All "they" know about is "one-click installers". And why not? Choice enough: Freemat, Scilab, ML itself, etc. This audience has simply made its choice already a long time ago: easier & less dependence = better. Good luck educating them otherwise. 3. Intended gain (Referring to your 1st post about unneeded code) What's the point of having a package mgmt system, if for the vast majority of intended users -who start from scratch- it makes almost no difference whether they get about the same files and same amount of bytes via a package manager or from a monolithic installer? Some simple weeding in the current .7z archives may be much more effective. Another thing here: We regularly get reports that Octave is used in courses. Imagine tens or hundreds, or more, students all trying to install Octave simultaneously over the school/uni network using a package manager d/l-ing from SF. That school/uni had better have a monolithic Octave installer somewhere on the LAN, and that would be better for SF's bandwidth, too. To summarize: What do you want to achieve with trying to improve Windows-Octave's distribution/installation mechanism? </SKEPTICAL MODE> Philip |
From: Bogdan <lov...@ya...> - 2012-07-21 19:19:21
|
Hi, Let me address your concerns in order. 1. Developer focus. As you've suggested later in the post, I could prepare the package myself. 2. User perception. I think you are not only underestimating your target audience but also grossly exaggerating the difficulty of this task; if anything, it should make their lives easier, not more difficult. First of all, they are Windows users and thus should know how to use an installer. Secondly, I'm pretty certain people who are interested in using numerical analysis software are capable of pulling though. Recently, hooks were added to mingw-get so that its GUI wrapper can list packages in a similar fashion to Cygwin. For people who prefer to use mingw-get directly, there is documentation on it on MinGW's website. Octave-Forge could also provide the command line required just in case anyone is interested. 3. Intended gain. I think it's the other way around. If it makes almost no difference for the vast majority of users, why not also make the lives of MinGW users easier? (Also consider point 2 when answering this.) Let me explain the difference it would make by taking my example. I use the MinGW environment for software development and use Octave because it helps me develop and analyse complex algorithms. That means I always need to keep two MSYS sessions open. Let me know whether the above arguments have persuaded you so we can decide what the best course of action is (there is a bit more to talk about if I have succeeded). Cheers, Bogdan |
From: Bogdan <lov...@ya...> - 2012-07-21 19:29:21
|
Hi again. Oops, I forgot to address the SourceForge bandwidth concern. The packages installed by mingw-get don't need to be downloaded from SourceForge everytime. Those unversities would provide mingw-get and the packages locally, and mingw-get would be used to install them. Cheers, Bogdan |
From: Philip N. <pr....@hc...> - 2012-07-21 20:19:08
|
Bogdan wrote: > Hi, > > Let me address your concerns in order. > > 1. Developer focus. As you've suggested later in the post, I could > prepare the package myself. > > 2. User perception. I think you are not only underestimating your target > audience but also grossly exaggerating the difficulty of this task; if > anything, it should make their lives easier, not more difficult. First > of all, they are Windows users and thus should know how to use an > installer. Secondly, I'm pretty certain people who are interested in > using numerical analysis software are capable of pulling though. > > Recently, hooks were added to mingw-get so that its GUI wrapper can list > packages in a similar fashion to Cygwin. For people who prefer to use > mingw-get directly, there is documentation on it on MinGW's website. > Octave-Forge could also provide the command line required just in case > anyone is interested. > > 3. Intended gain. I think it's the other way around. If it makes almost > no difference for the vast majority of users, why not also make the > lives of MinGW users easier? (Also consider point 2 when answering > this.) Let me explain the difference it would make by taking my example. > I use the MinGW environment for software development and use Octave > because it helps me develop and analyse complex algorithms. That means I > always need to keep two MSYS sessions open. > > Let me know whether the above arguments have persuaded you so we can > decide what the best course of action is (there is a bit more to talk > about if I have succeeded). No they quite haven't, but that doesn't matter :-) I'll let myself be convinced by what comes out of it, rather than by endless discussions. I gave my opinion, enough said, now I shut up. But you did convince me of your determination; very well, may I suggest to give it a try. This is a volunteer project after all, I wasn't intending to oppose people who want to contribute. If you need info just post here. Philip |
From: Thomas W. <tw...@de...> - 2012-07-22 17:46:53
|
On Fri, Jul 20, 2012 at 07:12:56PM +0200, Philip Nienhuis wrote: > Thanks Thomas for an enlightening post. Indeed, there are more > perspectives and interests than just Octave users, developers etc. But I > have ambiguous feelings on this subject. <snipped rest of mail> I didn't want to change your decision[1]. As every non-trivial decision, building an installer and chosing its content is a compromise. As long as people are aware of what they are actually chosing, that's okay with me. [1] Given that I'm uploading a 100+ MB package with only debug symbols for Octave with every Debian package of it, that would be hypocritical - summed over all architectures and mirrors, I'm probably generating 100 GB traffic with each upload myself (10 architectures, ~100 mirrors). Thomas |
From: Philip N. <pr....@hc...> - 2012-07-22 22:04:18
|
Thomas Weber wrote: > On Fri, Jul 20, 2012 at 07:12:56PM +0200, Philip Nienhuis wrote: >> Thanks Thomas for an enlightening post. Indeed, there are more >> perspectives and interests than just Octave users, developers etc. But I >> have ambiguous feelings on this subject. > > <snipped rest of mail> > > I didn't want to change your decision[1]. My decision? Not sure what you mean, but I didn't build the MinGW installer; the credits should go to Nitzan Arani. > As every non-trivial decision, > building an installer and chosing its content is a compromise. As long > as people are aware of what they are actually chosing, that's okay with > me. Nitzan made an installer that allows about anything, including building .oct files and binary packages, etc. Soon after Tatsuro compiled Octave 3.3.91 for MinGW I put together a minimal but complete setup for a self-contained working win32 Octave environment for myself. That allows me to tell from a comparison with Nitzan's current binary that the overhead in the latter really isn't so very big. To be able to run Octave and compile a few procs, a lot of MinGW stuff is needed; that is unavoidable for an environment like win32 that is somewhat alien to *nix-based SW like Octave. To compare: Michael's MSVC version is much smaller (on disk 225 MB vs 950 MB for MinGW). But to compile s/th with the MSVC version, Visual C++ has to be installed as well, and the minimum size of that would be 2.2+ GB; of course probably 2.15 GB of which is just M$ bloat. > [1] Given that I'm uploading a 100+ MB package with only debug symbols > for Octave with every Debian package of it, that would be hypocritical - > summed over all architectures and mirrors, I'm probably generating 100 > GB traffic with each upload myself (10 architectures, ~100 mirrors). Traffic and storage is only one side of the picture. I once read somewhere that a trivial Google search costs as much natural resources as an average household uses in several weeks (or longer). Whether that holds exactly true or not, the message is that there's really a lot of waste in contemporary use of IT, and especially that most of that waste is not at all obvious. In fact, this is something that holds for many socio-economical processes these days. So in a way I was pleasantly surprised by your post, in the sense that scarcity of resources is at least being considered (BTW I'm not so much of a greenie). Philip |
From: Bogdan <lov...@ya...> - 2012-07-22 22:53:18
|
Hi, I have asked the MinGW people whether they will accept the package---all we can do now is wait. I hope they will accept it but it's worth pointing out that they've declined other GNU package offerings before, and even the offer of the MinGW-w64 people to combine the two projects. Anyway, is this Nitzan person, that you have mentioned, still active and can (s)he be contacted? Cheers, Bogdan |
From: nitnit <ni...@gm...> - 2012-07-23 07:02:04
|
Bogdan wrote > > > Anyway, is this Nitzan person, that you have mentioned, still active and > can (s)he be contacted? > > Yes, I am active and watching this thread. The mingw octave/octaveforge binaries packages on sourceforge are based on Tatsuro's mingw libraries and have been compiled and packaged by me for my personal usage at the time when I have looked for an updated octave binaries for windows after the previous maintainer (Benjamin Lindner) has quit. I have contributed the outcome of this effort so other windows users can use it, and also have kept updating these packages in way that they can be easily used, and have compromised on size. As for packaging a more effective (smaller and still flexible) distribution, it might be possible, but it requires a much bigger effort - mainly for making the dev. tools and environment automatically getting and building the octave/octaveforge dependencies. For most of these, I didn't built the dependencies by myself, but have used other mingw developers work. I think that making such an "effective installer" is beyond my skills and spare time. As Philip mentioned before, I even didn't found the time yet to properly document and publish all the patches I have done for the octaveforge packages in order for them to compile under mingw. My patches can not be applied to the octaveforge source as they are because they should be revised for not breaking the compatibility to other systems. Nitzan -- View this message in context: http://gnu-octave-repository.2306053.n4.nabble.com/Regarding-the-MSYS-installer-tp4655444p4655473.html Sent from the octave-dev mailing list archive at Nabble.com. |
From: Jordi G. H. <jo...@oc...> - 2012-08-21 17:18:20
|
On 23 July 2012 03:01, nitnit <ni...@gm...> wrote: > I think that making such an "effective installer" is beyond my skills and > spare time. As Philip mentioned before, I even didn't found the time yet to > properly document and publish all the patches I have done for the > octaveforge packages in order for them to compile under mingw. My patches > can not be applied to the octaveforge source as they are because they should > be revised for not breaking the compatibility to other systems. I have been worried about this problem. This, in effect, is a GPL violation. It's worrying that we are sanctioning Octave binaries that are in violation of the GPL. You say you don't have time, but all you have to do is publish your modified sources. You don't have to clean up the patches or worry if they will or won't be included in the main repository. Please just dump your changes without worrying if we'll like it or not. We ought to be sharing the efforts for Windows compilation anyways if we're going to be making better Windows binaries as a community. - Jordi G. H. |
From: Bogdan <lov...@ya...> - 2012-07-28 09:15:35
|
Hi, No, no. I wasn't asking you to prepare the MinGW package---I promised to do that. I was going to ask whether you have the time to document the work. Right now, I am waiting on the MinGW crew to decide what they want to do. There are two ways to proceed: 1. To host builds on the MinGW SF page in the form of installable packages, just like everything else is dealt with. That doesn't mean Octave-Forge can't continue to provide its giant archives. :-) 2. To host the MinGW packages elsewhere (preferably Octave-Forge). However, in this case, the user would have to modify their profiles.xml file that comes with mingw-get. This would be annoying. If they want to go for option 1, they will become the package maintainers. If they want to go for option 2, I will. Cheers, Bogdan -- View this message in context: http://gnu-octave-repository.2306053.n4.nabble.com/Regarding-the-MSYS-installer-tp4655444p4655515.html Sent from the octave-dev mailing list archive at Nabble.com. |
From: Bogdan <lov...@ya...> - 2012-08-21 15:37:49
|
Hi again, Sadly, it seems like I am forced to drop the project. The MinGW developers have the habit to simply not check tickets (sometimes in the middle of the conversation; even if they're expecting a patch) and the Octave-Forge community also seems disinterested... or maybe Nitzan just doesn't have the time to document what he did; I'm not judging. Cheers, Bogdan -- View this message in context: http://octave.1599824.n4.nabble.com/Regarding-the-MSYS-installer-tp4632442p4643044.html Sent from the Octave - Dev mailing list archive at Nabble.com. |
From: Bogdan <lov...@ya...> - 2012-08-21 15:38:20
|
Hi again, Sadly, it seems like I am forced to drop the project. The MinGW developers have the habit to simply not check tickets (sometimes in the middle of the conversation; even if they're expecting a patch) and the Octave-Forge community also seems disinterested... or maybe Nitzan just doesn't have the time to document what he did; I'm not judging. Cheers, Bogdan -- View this message in context: http://octave.1599824.n4.nabble.com/Regarding-the-MSYS-installer-tp4632442p4643045.html Sent from the Octave - Dev mailing list archive at Nabble.com. |
From: Bogdan <lov...@ya...> - 2012-08-21 15:38:53
|
Hi again, Sadly, it seems like I am forced to drop the project. The MinGW developers have the habit to simply not check tickets (sometimes in the middle of the conversation; even if they're expecting a patch) and the Octave-Forge community also seems disinterested... or maybe Nitzan just doesn't have the time to document what he did; I'm not judging. Cheers, Bogdan -- View this message in context: http://octave.1599824.n4.nabble.com/Regarding-the-MSYS-installer-tp4632442p4643046.html Sent from the Octave - Dev mailing list archive at Nabble.com. |