Forgot your password?
typodupeerror

Comment: Re:Systemd? Not on my system... (Score 1) 224

by pthisis (#47484343) Attached to: X.Org Server 1.16 Brings XWayland, GLAMOR, Systemd Integration

No, generally emacs users are happy with systems that have both emacs and vi, and emacs won't prevent vi (and all the tools depending on ex/ed) from working.

Except when distributions screw up their dependencies, which they almost all did for about the first 10 years.

Emacs' crappy legacy ctags was part of the emacs package rather than a separate ctags package (despite the fact that emacs itself prefers etags). Hence it was impossible to install emacs and have modern functional code navigation in vi (vim/elvis/nvi) without overriding the rpm/dpkg dependencies or some other hack.

(This is not emacs' fault, it's the distributors who screwed it up for years).

Comment: Of course (Score 0) 28

by pthisis (#47420059) Attached to: The Video Game That Maps the Galaxy

Braben boasts that his games predicted extra-solar planets ('These were pretty close to those that have been since discovered, demonstrating that there is some validity in our algorithms'), and that the game's use of current planet-formation theories has shown the sheer number of different systems that can exist according to the rules, everything from nebulous gas giants to theoretically habitable worlds.

Starflight did this in 1986.

Comment: Re:Free Speech (Score 1) 646

by pthisis (#47269435) Attached to: Washington Redskins Stripped of Trademarks

This is not a free speech issue. You are allowed to say and write "redskin" anywhere you wish. You just can't trademark it.

Yes, you can. This decision explicitly doesn't revoke the team's right to use the trademark "Redskins". It removes it from the USPTO primary registry, but it doesn't revoke the trademark (in other words, what was an (R) is now a (TM)).

Comment: Re:My two cents (Score 1) 646

by pthisis (#47269389) Attached to: Washington Redskins Stripped of Trademarks

They had a trademark on their brand. The feds decide they don't like the mark so they take it away. The owners end up being harmed economically all because the government didn't like the descriptive nature of the brand. They've effectively stifled the free speech of the owner by denying them the use of the mark.

Please read the decision. They have done no such thing, and haven't cancelled the trademark. They've removed it from the primary registry. The team still has full protected (TM) rights, and third parties won't be allowed to make knockoff jersey with the name on it or anything like that. It's just not a registered (R) trademark anymore.

From the decision:
This decision concerns only the statutory right to registration under Section 2(a). We lack statutory authority to issue rulings concerning the right to use trademarks. See, e.g., In re Franklin Press, Inc., 597 F.2d 270, 201 USPQ 662, 664 (CCPA 1979).

Comment: Re:My two cents (Score 1) 646

by pthisis (#47269373) Attached to: Washington Redskins Stripped of Trademarks

The trademark exists to protect their business interest in the brand name. The feds aren't canceling the mark because other business entities want to use it, they're canceling the mark because the feds don't like it.

This is wrong. The feds aren't canceling the trademark, period. They are canceling its presence on the USPTO primary registry (where it's not allowed to be under the Lanham act), but it'll still be a (TM) trademark with court protection (just not an (R) registered trademark).

From the decision itself:

This decision concerns only the statutory right to registration under Section 2(a). We lack statutory authority to issue rulings concerning the right to use trademarks. See, e.g., In re Franklin Press, Inc., 597 F.2d 270, 201 USPQ 662, 664 (CCPA 1979).

Comment: Re:My two cents (Score 1) 646

by pthisis (#47269359) Attached to: Washington Redskins Stripped of Trademarks

The government is not restricting speech at all. The summary is hopelessly dumb: the decision doesn't strip the team of their trademarks, it simply removes them from the USPTO registry as required by the Lanham act. They'll still be protected (TM) trademarks that nobody except the owner is allowed to use, they just aren't (R) registered (which has implications on venue and damages).

From the decision itself:

This decision concerns only the statutory right to registration under Section 2(a). We lack statutory authority to issue rulings concerning the right to use trademarks. See, e.g., In re Franklin Press, Inc., 597 F.2d 270, 201 USPQ 662, 664 (CCPA 1979).

Comment: Re:Type of applications (Score 2) 466

by pthisis (#47242145) Attached to: Ask Slashdot: Best Rapid Development Language To Learn Today?
awk is fine for one-liners and for simple takes on moderately large files can be 5-6x faster than Perl.  For all that perl has the reputation for being a grep/sed/awk replacement, it's incredibly slow at the job.  Sometimes that matters.

For anything larger than a one-off, I'd go with python/pypy (ruby and lua are also fine choices).

$ time awk '{print $1}' < f4.txt >/dev/null

real    0m0.296s
user    0m0.288s
sys    0m0.004s

$ time perl -pale '$_="@F[0]"' < f4.txt >/dev/null

real    0m1.920s
user    0m1.896s
sys    0m0.020s

$ time python -c "import sys;[sys.stdout.write(line.split()[0]+'\n') for line in sys.stdin]" < f4.txt >/dev/null

real    0m0.618s
user    0m0.604s
sys    0m0.008s

$ time pypy -c "import sys;[sys.stdout.write(line.split()[0]+'\n') for line in sys.stdin]" < f4.txt >/dev/null

real    0m0.531s
user    0m0.508s
sys    0m0.020s

Comment: Re:Feels Dated (Score 1) 435

by pthisis (#46934533) Attached to: C++ and the STL 12 Years Later: What Do You Think Now?

I think that Slashdot ate some of your formatting (angle brackets?). I'm not sure how the hash table is used for messaging (you might want to consider Unix domain sockets for messaging, depending on what's going on). But...

You can basically grow shared memory segments on the fly. They're shared in the FS page cache, so if you create a "new" memory mapping on the same backing file that's just bigger, it'll contain all the same stuff in the original segment as the original mapping.

So you just:

a = mmap(..., 2 megabytes,...)

(Use for a while, realize that it's too small)

old = a
new = mmap(..., 4 megabytes, ...)
a = new
munmap(old)

You have to do that per-process, but you can either have the initial part of the memory indicate the mapping length (every time you use it, check the length and reallocate if you're off) or you can use a semaphore or socket message or other OOB message to indicate when to resize.

I don't see how this is (theoretically) any harder in C++ than in Java as far as the problem specifics go (I mean ignoring general reasons that C++ is harder than Java).

Also when they say that a python Manager object is slow, access to it should be considered similar to access to a synchronized method in Java. But reading large amounts of data over it can be problematic, depending on exactly how you're using it.

Depending on your access needs and where your bottlenecks are, I'd also consider using memcached or something like that if you think you might ever expand to multiple machines.

Comment: Re:Feels Dated (Score 1) 435

by pthisis (#46931753) Attached to: C++ and the STL 12 Years Later: What Do You Think Now?

Go doesn't have support for fork without exec, or at least didn't last time I looked at it.

I need async execution of things with read access to lots of data, and write access to their own data.

This sounds like shared memory segments to me. You can enforce memory protection by having separate mappings per process that are only writeable by the owner, with the processes running as separate users. That's safest but requires separate users and can be a headache for some tasks. Alternatively you could rely on the open/map calls being right and use read-only mode there but run as one user (you'd still protect against random pointer bugs, mistakes about which data structures you're writing into, etc as long as the open calls were correct).

ALL I need is synchronization

What kind of synchronization? What are your performance requirements? You may want want to consider simple mutexes, spinlocks, token passing, or read-copy-update depending on what you're doing.

Comment: Re:Feels Dated (Score 1) 435

by pthisis (#46923321) Attached to: C++ and the STL 12 Years Later: What Do You Think Now?

BTW the basic architecture choices are similar across most languages; whether it's C or Python or Lisp or C++ or whatever, you're looking at a handful of common primitives for synchronization and data sharing, often with thin language-specific wrappers around them.

The most common times that there's a major difference is when either in a highly functional language designed around concurrency (e.g. erlang) or a language that isolates you so much from the environment that you can't easily use common primitives (Java's inability to get to multiprocess calls is the most obvious example).

Comment: Re:Feels Dated (Score 1) 435

by pthisis (#46923235) Attached to: C++ and the STL 12 Years Later: What Do You Think Now?

I'd need to know more about your app to make a real recommendation, but in general for multiprocessing I'd use fork without exec to spawn new processes; they will share memory in a copy-on-write manner, so the python interpreter itself and other read/execute only memory will be shared between all processes.

There are numerous approaches to data sharing--sockets/pipes for streaming data and memory-maps for shared memory segments (memory maps are generally preferrable to SysV shm segments, IMO), and either token passing via pipes or something like multiprocessing.Lock for synchronization.

Your cells may want an event-driven state machine model. It's tough to say without knowing more about the app.

"The Amiga is the only personal computer where you can run a multitasking operating system and get realtime performance, out of the box." -- Peter da Silva

Working...