[Mono-list] .Net based report generation on windows and linux without installed office applications
Dear Developers, I would like to ask for some information you if you know about a program that runs on linux (so can be developped with mono) or is a cross-platform program managing to generate a report of spreadsheets or documents, and if the program can run without having an office installed on the PC? Thanks, Attila -- View this message in context: http://old.nabble.com/.Net-based-report-generation-on-windows-and-linux-without-installed-office-applications-tp27358291p27358291.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] undefined symbol :apr_sockaddr_port_get
Hi I have encountered some error to start httpd httpd:Syntax error on line 210 of /etc/httpd/conf/http.conf : Syntax error on line 8 of /etc/httpd/conf.d/mod_mono.conf :Cannot load /usr/lib/httpd/modules/mod_mono.so into server: /usr/lib/httpd/modules/mod_mon.so :undefined symbol : apr_sockaddr_port_get I downloaded xsp-1.9.1-0.novell.norach.rpm, mod_mono-1.0-0.rhel4.novell.i386.rpm then installed them using rpm -ivh why I got this error? what's wrong with my installing? anybody can help me? -- View this message in context: http://old.nabble.com/undefined-symbol-%3Aapr_sockaddr_port_get-tp27335707p27335707.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mono performance, 20x differential with Java (what am i doing wrong)
Hey On Sat, Jan 30, 2010 at 11:08 PM, James Mansion < ja...@mansionfamily.plus.com> wrote: > Alan McGovern wrote: > >> Feel free to contribute the changes required to remove the limitations on >> when/where mono performs TCO. That would allow you to contribute F# patches >> if you wish. >> > I'm intrigued - why say that? I mean - what's the point? What are you > trying to achieve, really? > I say it because he expressed an interest in contributing to mono in the email I responded to. He is also, by his own word, quite familiar with VM technology in general so he'd be an ideal candidate to contribute a patch if he wished to and had the time to do so. He also appears to be quite familiar with TCO so he'd know all the cases which would need to be deault with. There is no ulterior motive here. Alan. > If someone has domain knowledge and implementation skills on top of CLR but > can show that Mono is defective, its efinitely reasonable to ask them to > give 'the mono development community' a test case and bug report. > > But expecting them to climb the mountain of learning to fiddle with a > particular CLR implementation's core is nuts, particularly when they have an > alternate that works for them to do their day job. If someone wanted to > climb that mountain and make the changes, then presumably they would want to > start by reading the copious up to date detailed design documentation and > implementation notes on how (and why) it works now, so that they could size > the task. Oh wait ... :-( > > Its much, much more efficient for someone who already groks the internals > to make fiddly low-level changes, particularly if getting them into the > release stream requires a lot of trust relationship with the release > masters. I think you do a huge disservice to everyone by trying to get > outsiders to work on something like that - or perhaps you just want people > with bad news to go away so you can paper over the cracks? > > Please, ask for test cases and reports. FWIW I suspect (justa hunch, I'm > certainly not an expert) from what's been said that if a calling convention > change is needed (and I seem to remember there are some issues that prevent > fuller use of LLVM that one might also want to consider if that sort of > change is on the cards) then its as much a political and > major-version-compatibility issue as it is technical, and once again asking > someone to work on patches in such a situation is laughable, given the > degree of risk that they might completely waste their time. > > > James > > ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mono performance, 20x differential with Java (what am i doing wrong)
James, just FYI, Miguel indicates that the mono team does plan to support TCO / F# fully. I am also hoping that mono will continue to build out to the LLVM backend given the amount of investment that's been put into LLVM. The performance results look very promising (I am waiting for 64 bit support on OSX to test it out for myself). This is an open source project, for which some of us benefit for free. So from that perspective I think it is fair to try to solicit work from parties of interest. However, as you point out, someone like myself is not really a developer in the VM space, so for me would be inappropriate. I do numerical work and trading in the financial markets ... On Jan 30, 2010, at 6:08 PM, James Mansion wrote: > Alan McGovern wrote: >> Feel free to contribute the changes required to remove the limitations >> on when/where mono performs TCO. That would allow you to contribute F# >> patches if you wish. > I'm intrigued - why say that? I mean - what's the point? What are you > trying to achieve, really? > > If someone has domain knowledge and implementation skills on top of CLR > but can show that Mono is defective, its efinitely reasonable to ask > them to give 'the mono development community' a test case and bug report. > > But expecting them to climb the mountain of learning to fiddle with a > particular CLR implementation's core is nuts, particularly when they > have an alternate that works for them to do their day job. If someone > wanted to climb that mountain and make the changes, then presumably they > would want to start by reading the copious up to date detailed design > documentation and implementation notes on how (and why) it works now, > so that they could size the task. Oh wait ... :-( > > Its much, much more efficient for someone who already groks the > internals to make fiddly low-level changes, particularly if getting them > into the release stream requires a lot of trust relationship with the > release masters. I think you do a huge disservice to everyone by trying > to get outsiders to work on something like that - or perhaps you just > want people with bad news to go away so you can paper over the cracks? > > Please, ask for test cases and reports. FWIW I suspect (justa hunch, > I'm certainly not an expert) from what's been said that if a calling > convention change is needed (and I seem to remember there are some > issues that prevent fuller use of LLVM that one might also want to > consider if that sort of change is on the cards) then its as much a > political and major-version-compatibility issue as it is technical, and > once again asking someone to work on patches in such a situation is > laughable, given the degree of risk that they might completely waste > their time. > > > James > > ___ > Mono-list maillist - Mono-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mono performance, 20x differential with Java (what am i doing wrong)
Alan McGovern wrote: > Feel free to contribute the changes required to remove the limitations > on when/where mono performs TCO. That would allow you to contribute F# > patches if you wish. I'm intrigued - why say that? I mean - what's the point? What are you trying to achieve, really? If someone has domain knowledge and implementation skills on top of CLR but can show that Mono is defective, its efinitely reasonable to ask them to give 'the mono development community' a test case and bug report. But expecting them to climb the mountain of learning to fiddle with a particular CLR implementation's core is nuts, particularly when they have an alternate that works for them to do their day job. If someone wanted to climb that mountain and make the changes, then presumably they would want to start by reading the copious up to date detailed design documentation and implementation notes on how (and why) it works now, so that they could size the task. Oh wait ... :-( Its much, much more efficient for someone who already groks the internals to make fiddly low-level changes, particularly if getting them into the release stream requires a lot of trust relationship with the release masters. I think you do a huge disservice to everyone by trying to get outsiders to work on something like that - or perhaps you just want people with bad news to go away so you can paper over the cracks? Please, ask for test cases and reports. FWIW I suspect (justa hunch, I'm certainly not an expert) from what's been said that if a calling convention change is needed (and I seem to remember there are some issues that prevent fuller use of LLVM that one might also want to consider if that sort of change is on the cards) then its as much a political and major-version-compatibility issue as it is technical, and once again asking someone to work on patches in such a situation is laughable, given the degree of risk that they might completely waste their time. James ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mono performance, 20x differential with Java (what am i doing wrong)
Feel free to contribute the changes required to remove the limitations on when/where mono performs TCO. That would allow you to contribute F# patches if you wish. Contributors and patches are always welcome. Alan. On Sat, Jan 30, 2010 at 4:51 PM, Jon Harrop wrote: > On Saturday 30 January 2010 12:59:43 Jonathan Shore wrote: > > On Jan 29, 2010, at 9:42 PM, Rodrigo Kumpera wrote: > > > By the way, guys, the mono community is very welcoming to both external > > > contribution and feedback. So if you guys make a compelling case for > TCO, > > > maybe Miguel can get someone to have it fixed. > > > > Well, I'm not sure how to make a compelling case ; ), other than that to > > allow standard F# programs to execute on mono would require TCO. TC's > are > > a fundamental in F#. > > And F# will be a standard .NET language as part of VS2010 in 2 months. > > > I'm not sure how big the F# community is. I would guess it is not that > > large at the moment, but seems to have a lot of growth. > > The F# Hub has 16,582 registered members. The mono-devel Ubuntu package has > 19,792 installs and 2,309 active users. > > If the F# community is not already bigger than the Mono community then it > certainly will be when Microsoft drop it on 10,000,000 developers for free > in > March. > > > F# joining the list of fully supported languages in VS2010 should attract > > much wider use. Some of these users will be looking for a cross-platform > > solution. > > I believe two or three of our ~1,000 customers is trying to use F# on Linux > or > Mac OS X. > > > If it counts for anything, would love to be able to use this on mono ;) > > Yes. Many people (such as myself) would also be far more inclined to > contribute code to Mono if it could be written in F#. I have no desire to > write C#. > > -- > Dr Jon Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/?e > ___ > Mono-list maillist - Mono-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mono performance, 20x differential w ith Java (what am i doing wrong)
On Saturday 30 January 2010 12:59:43 Jonathan Shore wrote: > On Jan 29, 2010, at 9:42 PM, Rodrigo Kumpera wrote: > > By the way, guys, the mono community is very welcoming to both external > > contribution and feedback. So if you guys make a compelling case for TCO, > > maybe Miguel can get someone to have it fixed. > > Well, I'm not sure how to make a compelling case ; ), other than that to > allow standard F# programs to execute on mono would require TCO. TC's are > a fundamental in F#. And F# will be a standard .NET language as part of VS2010 in 2 months. > I'm not sure how big the F# community is. I would guess it is not that > large at the moment, but seems to have a lot of growth. The F# Hub has 16,582 registered members. The mono-devel Ubuntu package has 19,792 installs and 2,309 active users. If the F# community is not already bigger than the Mono community then it certainly will be when Microsoft drop it on 10,000,000 developers for free in March. > F# joining the list of fully supported languages in VS2010 should attract > much wider use. Some of these users will be looking for a cross-platform > solution. I believe two or three of our ~1,000 customers is trying to use F# on Linux or Mac OS X. > If it counts for anything, would love to be able to use this on mono ;) Yes. Many people (such as myself) would also be far more inclined to contribute code to Mono if it could be written in F#. I have no desire to write C#. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mono performance, 20x differential with Java (what am i doing wrong)
On Jan 29, 2010, at 9:42 PM, Rodrigo Kumpera wrote: > > Implementing proper TCO in mono requires 2 things. First is to change the > managed calling convention to > have the caller pop its arguments. Then to lift any other few minor > restrictions. Well probably have similar > restrictions as MS's, such as no TCO on synchronized method. > Thanks > > There is a not very usually explored bit of hidden performance in .NET which > is > runtime code generation. It is trivial to produce code that does runtime > algorithm > specialization. You can even do most of it at high level in C# using > expression trees. > I used this facility a few yrs ago. It's quite nice. I think it was Reflect.Emit. Basically took a finance related DSL and compiled it on the fly. It's probably changed a lot since then. > > By the way, guys, the mono community is very welcoming to both external > contribution > and feedback. So if you guys make a compelling case for TCO, maybe Miguel can > get > someone to have it fixed. Well, I'm not sure how to make a compelling case ; ), other than that to allow standard F# programs to execute on mono would require TCO. TC's are a fundamental in F#. I'm not sure how big the F# community is. I would guess it is not that large at the moment, but seems to have a lot of growth.F# joining the list of fully supported languages in VS2010 should attract much wider use. Some of these users will be looking for a cross-platform solution. If it counts for anything, would love to be able to use this on mono ;) > > Cheers, > Rodrigo > > ___ > Mono-list maillist - Mono-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
