- [ANN] U++ 2015.2 released (rev 9251) - 6 Updates
- A "better" C++ - 2 Updates
| scott@slp53.sl.home (Scott Lurndal): Dec 01 09:01PM >Editor now truncates files longer than 200MB / 1GB (32/64 bits ide) while l= >oading, makes them read-only. This is considered a feature? |
| Vir Campestris <vir.campestris@invalid.invalid>: Dec 01 09:14PM On 01/12/2015 21:01, Scott Lurndal wrote: >> Editor now truncates files longer than 200MB / 1GB (32/64 bits ide) while l= >> oading, makes them read-only. > This is considered a feature? Well... When did you last see one that big? But I don't know why they bothered to put in such an arbitrary restriction. Andy |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 01 09:19PM On Tue, 2015-12-01, Vir Campestris wrote: >> This is considered a feature? > Well... When did you last see one that big? But I don't know why they > bothered to put in such an arbitrary restriction. I first parsed "truncates files ... while loading" as "if you accidentally try to open such a file, the editor will destroy it", but I suppose only the editor /buffer/ gets truncated. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Robert Wessel <robertwessel2@yahoo.com>: Dec 01 03:22PM -0600 On Tue, 01 Dec 2015 21:01:41 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >>Editor now truncates files longer than 200MB / 1GB (32/64 bits ide) while l= >>oading, makes them read-only. >This is considered a feature? I think the implication is that the previous behavior was to truncate the file on load and then let it be edited as normal (less the end of the file). The new behavior is clearly an improvement over that. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 01 01:24PM -0800 On Tuesday, 1 December 2015 23:14:24 UTC+2, Vir Campestris wrote: > > This is considered a feature? > Well... When did you last see one that big? But I don't know why they > bothered to put in such an arbitrary restriction. People sometimes turn quite large database into multi-gigabyte xml or json. Most text editors will start to act oddly. Some can handle such files ... with a plugin at least: http://www.vim.org/scripts/script.php?script_id=1506 |
| Mirek Fidler <cxl@ntllib.org>: Dec 01 02:03PM -0800 > I think the implication is that the previous behavior was to truncate > the file on load and then let it be edited as normal (less the end of > the file). The new behavior is clearly an improvement over that. Well, previous behavior was to run out of memory in 32-bits and load file just fine in 64-bits, unfortunately over 1GB it takes too long to load (like tens of seconds long). As for the purpose of loading such big files, I regulary need to load big and edit 800MB backend logs. BTW, we are quite proud that theide can even edit such long files and load them relatively quickly (like 200MB/s from SSD). You can try with any existing source code editor - most of them crash or freeze at 100MB :) |
| Lynn McGuire <lmc@winsim.com>: Dec 01 02:33PM -0600 On 12/1/2015 12:52 AM, Christian Gollwitzer wrote: >> http://cci.lbl.gov/fable/ > Interesting! Thank you for this hint! > Christian You are welcome. I would appreciate a report here when you have tried it out. Lynn |
| Vir Campestris <vir.campestris@invalid.invalid>: Dec 01 09:16PM On 30/11/2015 21:22, Lynn McGuire wrote: > http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html > Huh, Pascal is #11 and #17. I would have never thought it was in the > top 50 anymore. "Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings." which explains why Algol isn't there ;) - nobody uses it on the 'Net! Andy |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment