Re: Getting an array into a C program through mathlink
- To: mathgroup at smc.vnet.net
- Subject: [mg130345] Re: Getting an array into a C program through mathlink
- From: "John D. Hendrickson and Sara Darnell" <johnandsara2 at cox.net>
- Date: Wed, 3 Apr 2013 22:52:37 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Delivered-to: l-mathgroup@wolfram.com
- Delivered-to: mathgroup-newout@smc.vnet.net
- Delivered-to: mathgroup-newsend@smc.vnet.net
- References: <khsbap$35l$1@smc.vnet.net> <20130401050011.AD2D46AE5@smc.vnet.net> <3098095B-C283-4E66-9677-1556474225FC@wolfram.com> <515B55FE.2070906@cox.net> <13698DB1-552E-43CC-A21A-22C0A2ACDD63@wolfram.com>
- Reply-to: johnandsara2 at cox.net
you've crossed your own testimony "we're very careful about compile targets" doesn't mean it works. you've said if MathLink doesn't work Mathematica won't either certainly isn't true. I run Mathemaitca but can't make ANY mathlink apps. not after I upgraded from (woody to sarge). If you don't know why then why comment on the subject? I did find a way to do addtwo: which WR could have done but didn't. I said wasn't talking about Mathematica's own binaries but mathlink apps users made and posted for others to compile and use: which is what Mathematica's documentation implies why one might be using mathlink. You skirt the fact I'm not the only one who runs Mathematica and could not get mathgl3d / mathview3d to compile and run and reported it. Which was because I upgraded my OS to a slightly newer version. For example if I compile against old libs libML.a might not seg-fault: but that forces GL to link against old GL libs: which won't work against new GL libs runtime. That's assuming the rest worked, which i said had similar breakage issues. That's due to libML.a And GL isn't the only lib one might run into like that: all too many such will happen. and libML.a's insistance to be a backport is why. Your skirting the fact of how much trouble it is to backport like that only hoping it'd work on a new system when finished: it's an ass-whooping. what find install old OS to work on new PC? That's not what the mathgl3d author was thinking end users might be doing to run his nifty app is it? look i really don't want to talk about it any further. mathgl3d was the only mathlink project I wanted to see and it's not going to work. I made a makefile that does it. Yet again the use of it is too limited - it is bound to work only for examples and only given the particular way my OS version packaged old libs to be used. Again - i don't want to make or use any mathlink thinking i can distribute it to others. And a good reason is the above. I'll stick by my word and say: avoid mathlink if you plan others to use it, if you plan it to be portable over time. There will be lib issues you hadn't imagined. You can't get convince me to say otherwise can you? You have no evidence I do. John Fultz wrote: > If MathLink is broken, Mathematica is broken. MathLink is not just some toss-off library used in a few corner cases by a few random users and barely supported by Wolfram. It is a core part of the system, and if it's busted, Mathematica won't even run. I could point to a dozen binaries in the Mathematica distribution that work MathLink harder than most user programs do, but I really only need to point to two -- the Mathematica kernel and the Mathematica front end. MathLink is the one and only mechanism by which these two components communicate with each other. > > It is true that there can be dependencies on versions of operating systems and libraries. And to maintain maximum compatibility with a wide range of systems, we're very careful about which build systems and libraries we build our binaries (MathLink, FE, kernel, etc.) against, generally favoring somewhat older versions so we don't accidentally slurp in newer dependencies that could break on legacy systems. The range of operating systems and libraries Mathematica (and thus MathLink) work against are generally pretty well advertised, and we've done a pretty good job of supporting operating systems at least 5 years out of date (save on MacOS, where the user culture tends to be highly aggressive about updating operating systems, so the support window is a bit shorter). > > In summary, I would claim that, to the extent that your worries about MathLink are true, they apply to Mathematica itself. The fact that Mathematica is not constantly broken on every new Linux distribution suggests that your concerns, while not invalid, are not as serious as you seem to suggest. > > Sincerely, > > John Fultz > jfultz at wolfram.com > User Interface Group > Wolfram Research, Inc. > > > > On Apr 2, 2013, at 5:04 PM, "John D. Hendrickson and Sara Darnell" <johnandsara2 at cox.net> wrote: > >> Ok I think you asked for a little more info about why mathlink which seems fine on developer's machine might not be fine elsewhere. >> >> Why is because to work mathlink needs to link against OS libraries which change. >> >> http://reference.wolfram.com/mathematica/tutorial/MathLinkDeveloperGuide-Unix.html#725481284 >> >> clearly says it is library hooked and versional to specific libraries. >> >> http://support.wolfram.com/search/?query=mathlink&lang=en&noImg=1&submit.x=0&submit.y=0 >> >> are some problem reports of: >> >> LinkConnect::"linkc": "\!\(\[LeftSkeleton] 1 \[RightSkeleton]\) is dead; attempt to connect failed." >> >> (there were many unsure if wr has removed them. or search Google and find some. it's hard to believe you looked hard if you can't find any.) >> >> For example I have Mathematix Version zzz. I later upgrade Linux. Mathlink is now broken. I may be able to run simple pre-compiled ones (unlikely to be available for my exact linux disto) but most won't work because the libs have changed or they are for a different linux distro. You'd think "just recompile mathlink apps". NO. >> >> To resolve this I need to run Mathematica and any mathlink apps in a chroot of a previous Linux version. Compilation of other people's mathlink apps would also have to be done in the chroot - which won't work for newer mathlink apps. Too much effort. >> >> You'd think I can just compile against older libs: surprise that works at compile time but not run-time since libML.a is loaded accessed through the newer libs and it is older: IT WON'T EVER WORK. >> >> My other choice is to buy new mathematica. But if I had any mathlink apps I needed I'd have to rewrite them since they won't compile with the new linux libs / environment. This also requires a new computer. $$ And how long is it until it's all broken again? >> >> (obviously upgrading Mathematica is better if you have time and money for the "upgrade escapade") >> >> (Note I mean Linux distribution, the linux kernel isn't usually involved. unlike the old days: often binaries today often won't work when copied from one distro to another, due to lib variations they keep uploading) >> >> Obviously there's another answer: wolfram releases a different mathlink that doesn't rely on lib offsets runtime :) I won't go into it but I know what breaks it. >> >> -------------------------------- >> >> John Fultz wrote: >>> That's an interesting observation, but I can't say it matches my own experience. I've found MathLink to be remarkably compatible across major version number changes of Mathematica, and to be generally robust. It is the only way the FE and the kernel communicate with each other (not to mention other lesser components of the system), and the nature of that connection is not simple; I would say it uses a majority of the features that MathLink has to offer. >>> It's not clear to me exactly what you're referring to as "Wolfram problem reports". But I'd certainly be interested in knowing about any issues that you or anyone else may be experiencing with MathLink. >>> John Fultz >>> jfultz at wolfram.com >>> User Interface Group >>> Wolfram Research, Inc. >>> On Apr 1, 2013, at 12:00 AM, debguy <johnandsara2 at cox.net> wrote: >>>> my advice is to avoid mathlink because library issues cause >>>> compatibility problems (see Wolfram problem reports). ie after or >>>> without upgrade it's broken for someone trying to use. >>>> >>>> if you can accept fast but not fastest results I suggest this: >>>> >>>> to use "exec" in C to call math binary with piped commands (we're >>>> talking text input output) and use Put to get what into a file (can >>>> even be forked, run in background, doing it that way). then your >>>> application reads file when done (fread is fast, maybe not fast as >>>> direct read from mathlink). >>>> >>>> most tasks can be done without ever using C. doing some special >>>> graphics or something? >>>> > >
- References:
- Re: Getting an array into a C program through mathlink
- From: debguy <johnandsara2@cox.net>
- Re: Getting an array into a C program through mathlink