Bug#644136: ITP: ruby-text -- collection of text match and analysis algorithms
Package: wnpp Severity: wishlist Owner: Olivier Sallou * Package name: ruby-text Version : 1.1.2 Upstream Author : Paul Battley, Michael Neumann, Tim Fletcher * URL : https://rubygems.org/gems/Text * License : GPL Programming Lang: Ruby Description : collection of text match and analysis algorithms Library for match and analysis on text strings. Contains levenshtein distance calculation, Porter Stemming and others. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003073747.4361.29778.report...@debiansid.genouest.org
Bug#644137: ITP: ruby-cassiopee -- provide methods to search exact match or approximate matches with Hamming or edit distance
Package: wnpp Severity: wishlist Owner: Olivier Sallou * Package name: ruby-cassiopee Version : 0.1.8 Upstream Author : Olivier Sallou * URL : https://rubygems.org/gems/cassiopee * License : GPL Programming Lang: Ruby Description : provide methods to search exact match or approximate matches with Hamming or edit distance Library to search an exact or approximate word (hamming or edit distance) in a string. Support index cache with incremental update for later searches -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003074409.4386.41013.report...@debiansid.genouest.org
[RFC] License text parser and converter
DEP-5 is a good step forward to standardize copyright information. While it's indeed useful to determine a license type, there's no guarantee stand-alone license paragraphs or license headers are accurate (i.e. typos, GPL-2 license header while declaring GPL-2+), or canonically formatted (i.e. 72-char lines vs. 80-char lines, different spacing or indentation). Plus, some license text are not expressed in RFC822 syntax, and maintainers must adapt it to fit into DEP-5. As a reference, take MPL license, which is very long and fullfilled with spacing, converting it by hand is definitely time-consuming and error prone. I'd like to ask the following questions: * Is there a tool which, given a license text in raw format, converts it to match RFC822 syntax? * In case it exists, is it able to perform sanity checks on the licenses (i.e. license text matches intended one)? * In case it doesn't exist yet, would it be worth implementing it? * Which language would you use to implement it? I guess the answer to the last question would be Perl, as several related tools use Perl already (think of lintian, or libconfig-model-perl), but I suspect other scripting languages could fit as well. Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0mdnkkq1qnib6ybc7l+ae51wkwvyu-h0rjtq5nsemg...@mail.gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
On 2011-10-02 23:08, Henrique de Moraes Holschuh wrote: On Sun, 02 Oct 2011, Florian Weimer wrote: Couldn't we get rid of static libraries altogether, replacing static linking with ahead-of-time dynamic linking? [1] but I don't feel strong enough about it to get in the way if we do decide to drop static libs. I would defend static libs for scientific apps. Static libs show a significant performance benefit (2-40%, median around 5-10% but sometimes far more with C++ apps) and so are standard in HPC still; so I ship them in my packages even though they are not used much within the software shipped _by_ debian, but are used by our users. Note: this is for static libs without -fPIC. I'm not sure there is much benefit in shipping PIC static libs, (or potentially PIE codes); they are also highly unlikely to be used in 'web-facing' environments, and be security-sensitive; they are likely to be built by the user, used by that particular user alone, and hence should not be built with any security features( eg PIE) that cause performance degradation. -- Alastair McKinstry , , http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e898c5b.4010...@sceal.ie
Re: Bits from dpkg developers - dpkg 1.16.1
On Mon, Oct 03, 2011 at 11:20:11AM +0100, Alastair McKinstry wrote: > On 2011-10-02 23:08, Henrique de Moraes Holschuh wrote: > >On Sun, 02 Oct 2011, Florian Weimer wrote: > >>Couldn't we get rid of static libraries altogether, replacing static > >>linking with ahead-of-time dynamic linking? > > > I would defend static libs for scientific apps. Static libs show a > significant performance benefit (2-40%, median around 5-10% but sometimes > far more with C++ apps) and so are standard in HPC still; If you see that big a difference, you do a lot of cross-file calls in tight loops. This means you would greatly benefit of compiling with -flto instead. GCC doesn't allow linking flto objects from even slightly different compiler versions though as gimple format is not considered stable, so shipping precompiled static objects is no good. So what about shipping source instead so the user can optimize the heck out of it? -- 1KB // Yo momma uses IPv4! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003112333.ga2...@angband.pl
Re: Bits from dpkg developers - dpkg 1.16.1
* Henrique de Moraes Holschuh: > On Sun, 02 Oct 2011, Florian Weimer wrote: >> Couldn't we get rid of static libraries altogether, replacing static >> linking with ahead-of-time dynamic linking? > > Well, the normal usecase for static libraries and static linking is to > produce self-contained objects. If you can link a bunch of dynamic > objects into a self-contained object that behaves as a static-linked > object would, I'd say that yes, we could probably do away with static > libraries. It's technically conceivable in the sense that the required data is present in DSOs. I don't know if it's been implemented. > I do think it is a bad idea, though. We don't provide libraries just > for ourselves, we also provide them for the user to use when building > his own stuff and they might have other usecases. So it's probably necessary to continue compiling static libraries without -fPIC. This precludes statically linked PIE executables, but that's probably okay. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqiefgio@mid.deneb.enyo.de
debian on nokia N93i
Good day, Please if you have information provided can be installed on Nokia N93 with Symbian OS 9.1, S60 3rd edition, a version of Linux. thank you for the advice! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAEtuhQ0mevL8Oqfh=s1j7esuxwucoit7xwtoh4bzhqpteos...@mail.gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
* Adam Borowski: >> I would defend static libs for scientific apps. Static libs show a >> significant performance benefit (2-40%, median around 5-10% but sometimes >> far more with C++ apps) and so are standard in HPC still; > > If you see that big a difference, you do a lot of cross-file calls in > tight loops. Not necessarily. -fPIC and -fPIE force calls to global functions defined in the same translation unit to go through the PLT. They aren't translated to direct IP-relative calls. For -fPIC, this is required by the ELF specification (no kidding, this might seem strange today). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3eefcsv@mid.deneb.enyo.de
Re: debian on nokia N93i
On Mon, Oct 3, 2011 at 05:13, ..Blue...Genea.. wrote: > Good day, > Please if you have information provided can be installed on Nokia N93 > with Symbian OS 9.1, S60 3rd edition, a version of Linux. > > thank you for the advice! I am not a Debian Developer, but I have never heard of Linux being installed on a Nokia phone other than the N900, the N9 and the N950 (all designed for running Linux). The N93 uses an ARM11 cpu, which is rather weak for running Linux, and even if you got basics working, I am sure that the drivers are not there to make it really functional (e.g. able to make phone calls). Cheers, Kelly Clowers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFoWM=_VQsf1Rr=nhjzscfzvs5-798zm3vttzrdhgvtudms...@mail.gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
* Bastien ROUCARIES: > On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote: >> * Adam Borowski: >> I would defend static libs for scientific apps. Static libs show a significant performance benefit (2-40%, median around 5-10% but sometimes far more with C++ apps) and so are standard in HPC still; >>> >>> If you see that big a difference, you do a lot of cross-file calls in >>> tight loops. >> >> Not necessarily. -fPIC and -fPIE force calls to global functions >> defined in the same translation unit to go through the PLT. They >> aren't translated to direct IP-relative calls. For -fPIC, this is >> required by the ELF specification (no kidding, this might seem strange >> today). > > Could we add a gcc flag and be non conformant ? I'm not sure if this is worth the deviation from upstream. If we want to break ABI, there far better options. > I suppose it is only for using LD_PRELOAD. Not sure. LD_PRELOAD still works for cross-library calls, but it would cease to redirect library-internal calls. I really don't know why ELF does this. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcs6drx9@mid.deneb.enyo.de
Re: Bits from dpkg developers - dpkg 1.16.1
On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote: > * Adam Borowski: > >>> I would defend static libs for scientific apps. Static libs show a >>> significant performance benefit (2-40%, median around 5-10% but sometimes >>> far more with C++ apps) and so are standard in HPC still; >> >> If you see that big a difference, you do a lot of cross-file calls in >> tight loops. > > Not necessarily. -fPIC and -fPIE force calls to global functions > defined in the same translation unit to go through the PLT. They > aren't translated to direct IP-relative calls. For -fPIC, this is > required by the ELF specification (no kidding, this might seem strange > today). Could we add a gcc flag and be non conformant ? I suppose it is only for using LD_PRELOAD. Bastien > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/87d3eefcsv@mid.deneb.enyo.de > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAaWyJb7GGnQT4cj+A0c9748a0CtSB8XMij5gP=vfdd...@mail.gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
* Bastien ROUCARIES [111003 17:27]: > > Not necessarily. -fPIC and -fPIE force calls to global functions > > defined in the same translation unit to go through the PLT. They > > aren't translated to direct IP-relative calls. For -fPIC, this is > > required by the ELF specification (no kidding, this might seem strange > > today). > > Could we add a gcc flag and be non conformant ? I suppose it is only > for using LD_PRELOAD. Breaking -fPIC globally by changing gcc is a bad idea. (If any library needs the improvement, it can always specify what to call itself, which then has the added bonus of also doing this for calls between different translation units of the same library). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003173112.ga13...@server.brlink.eu
Re: Bits from dpkg developers - dpkg 1.16.1
* Alastair McKinstry [111003 12:48]: > I would defend static libs for scientific apps. Static libs show a > significant performance > benefit (2-40%, median around 5-10% but sometimes far more with C++ > apps) Are those numbers only the position independent code (I guess mostly the register available less) or also the PLT-relative calls? The latter can usually be reduced a bit by using making functions static, more by using -fvisibility=hidden (and marking to be exported symbols) and totally by visibility combined with aliases. So properly done (yes, yes, I know, scientific programming is the opposite of properly done) the only downsize would be the missing register, which should mostly only be measureable on 32 bit i386 programs. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003175439.gd13...@server.brlink.eu
Re: Bits from dpkg developers - dpkg 1.16.1
On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote: > On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote: > > Not necessarily. -fPIC and -fPIE force calls to global functions > > defined in the same translation unit to go through the PLT. They > > aren't translated to direct IP-relative calls. For -fPIC, this is > > required by the ELF specification (no kidding, this might seem strange > > today). > > Could we add a gcc flag and be non conformant ? I suppose it is only > for using LD_PRELOAD. -Bsymbolic, I think? GLib uses this to speed up internal calls, instead of the hacks with functions-having-two-names that it used to use. With either solution, if you want to LD_PRELOAD (as for GLib's refdbg tool) you have to have a second copy of GLib compiled to not do that, like libglib2.0-refdbg in Debian. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003183344.ga25...@reptile.pseudorandom.co.uk
