nitric-discuss — Discussions about the use of Nitrogen

[Nitric-discuss] Fwd: [ANN] macstl 0.2 -- portable SIMD toolkit, fast valarray transcendentals, fast Mach vectors

[Joshua J. <wan...@me...>]

Here's a project that would mesh very well with Nitrogen.

> From: gl...@pi...
> Subject: [ANN] macstl 0.2 -- portable SIMD toolkit, fast valarray 
> transcendentals, fast Mach vectors
> Date: 2 Feb 2005 04:32:24 -0800
> Newsgroups: 
> sci.math.num-analysis,comp.sys.mac.programmer.codewarrior,comp.sys.powerpc.tec
> h,comp.sys.mac.programmer.misc,comp.lang.c++
> Message-ID: <110...@o1...>
> 
> It has been a rough ride on the road from 0.1.5 (way back in 2003) and
> hard work and sleepless nights -- today, I'm proud to announce the
> immediate availability of macstl 0.2 -- the C++ header library designed
> to bring SIMD (single instruction multiple data) and the Mac into the
> world of modern generic programming.
> 
> http://www.pixelglow.com/macstl/
> 
> Just some of the new features:
> * Compiles on Xcode 1.5 gcc 3.3, Codewarrior 9.3 and Visual C++ .NET
> 2003.
> * Highly performant transcendental functions that are accurate to
> within 5 ulp. E.g. do a simple sin(x) * cos (y) + cos (x) * sin (y) and
> it will run 16.1x faster with Codewarrior on a G5 than a scalar loop of
> the same.
> * Automatic fused multiply-add optimizations for valarrays. Don't think
> fma, just code x * y + z -- or even w * x + y * z.
> * Complex number arithmetic that is 3.1x faster than scalar complex
> numbers.
> * Those missing opcodes in the Altivec core -- Integer division and
> modulus -- for all Altivec integer types. Faster than scalar division
> on random data.
> * Totally revamped, newly portable SIMD classes -- a valarray inside a
> SIMD register -- plug in your favorite SIMD CPU, reuse all the
> intrinsics or use the arithmetic you're used to since high school.
> 
> That not enough? How about these new areas:
> * Fully tested and benchmarked std::vector on the Mach allocator. Copy
> vectors 400x faster, insert into vectors 3x faster.
> * Adaptors for Core Foundation and Foundation classes, bridge them to
> STL and generic programming seamlessly.
> * A clean COM server implementation for CFPlugIns. No ugly ATL macros,
> well understood object lifetimes and best of all -- a super fast
> QueryInterface implementation.
> * Memory mapped containers. Share memory between your 64-bit process
> and your 32-bit GUI using STL conventions. Or just plain throw away
> your I/O and serialization code.
> 
> I've relicensed macstl for maximum flexibility. It's now a dual license
> under the open-source RPL and the proprietary PSL -- either you
> reciprocate all the code derived from mine, or you pay for a
> registration. Fees are competitive and low, and you get free upgrades,
> SVN access, priority support and eternal thanks from me!
> 
> Cheers, Glen Low
> ---
> pixelglow software | simply brilliant stuff
> www.pixelglow.com
>

[Nitric-discuss] Clearly I don't understand this stuff :-(

[Marshall C. <mar...@id...>]

OK - so I've got a Nitrogen-based app that makes windows.
I want to enable/disable menus based on the state of the frontmost window.

So, I install a window handler to handle
	static const EventTypeSpec kWindowEvents [] = {
		{ kEventClassCommand, kEventProcessCommand },
		{ kEventClassCommand, kEventCommandUpdateStatus }
	};

I do it like this ( which is what I _thought_ was correct )

N::InstallWindowEventHandler < WindowRef, WindowEventHandler >
	( window, GetEventTypeCount( kWindowEvents ), kWindowEvents 
).Release ();

And my window event handler looks like this:

void WindowEventHandler ( WindowRef theWindow,
		EventHandlerCallRef /* inCallRef */, EventRef inEvent );

So, I run the program, and when I drop down a menu, my handler gets 
called. Woo hoo!

Problem #1: The first parameter to the handler (the WindowRef) is 
always NULL. Looking at
the Nitrogen sources, I see that it's gotten from the refcon passed 
in at install time,
so that if I change my install line to read:

N::InstallWindowEventHandler < WindowRef, WindowEventHandler >
	( window, GetEventTypeCount( kWindowEvents ), kWindowEvents, 
window ).Release ();

all is well. This seems error prone to me. Shouldn't the WindowRef 
get propogated along automatically?

Problem #2:
	So, I do that, and look at the window, and try to enable or 
disable the menus.
I do this by calling:
	N::SetEventParameter< typeBoolean >( inEvent, 
kEventParamEnabled, *bool* );
where *bool* is a condition I calculated. I have stepped through the 
code, and convinced
myself that I am calcuating the condition correctly, yet the menu is 
never disabled. :-(
(I am returning normally from the event handler, not via exception, btw).

Any ideas here?

P.S.	Yes, I should probably be using the HICommandHandlers stuff, 
and I will, but
first I want to get this working - so that I can see how much better 
the HICommandHandlers do.
-- 
-- Marshall

Marshall Clow     Idio Software   <mailto:mar...@id...>

It is by caffeine alone I set my mind in motion.
It is by the beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.

Re: [Nitric-discuss] Next week

[Marshall C. <mar...@id...>]

At 11:28 PM -0700 7/14/04, Lisa Lippincott wrote:
>Hi folks,
>
>Sorry about being so hard to get to lately.  Moving is harder than I thought.
>
>I'll just reply to various things in this thread at random:
>
>I'd like to have a 0.9 release for the Adhoc CD, but I don't see a lot of
>"making it happen" energy in my immediate future.  (I am hoping to have
>enough to deal with some of the compatibility issues.)  And I agree we
>should be shooting for a 1.0 release, but I can't imagine we could do
>that for Adhoc.

I don't think so either.

As I said to Joshua in IM, I think that "Pending" needs to be empty
before we call anything 1.0 (along with docs, and maybe some more samples).
--
-- Marshall

Marshall Clow     Idio Software   <mailto:mar...@id...>

It is by caffeine alone I set my mind in motion.
It is by the beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.

Re: [Nitric-discuss] Next week

[Joshua J. <wan...@me...>]

On Jul 15, 2004, at 2:28 AM, Lisa Lippincott wrote:

> Hi folks,
>
> Sorry about being so hard to get to lately.  Moving is harder than I 
> thought.

Yeah, I'm trying to cut down this year.  :-)

> I'll just reply to various things in this thread at random:
>
> I'd like to have a 0.9 release for the Adhoc CD, but I don't see a lot 
> of
> "making it happen" energy in my immediate future.  (I am hoping to have
> enough to deal with some of the compatibility issues.)  And I agree we
> should be shooting for a 1.0 release, but I can't imagine we could do
> that for Adhoc.

Whatever we get done in time can go on the CD as Nitrogen 0.9.  A 1.0 
release at the conference is out of the question.  But we can use the 
mutual face time to discuss the thornier issues (i.e. those requiring 
low-latency, interactive conversation and group brainstorming) and set 
some release goals for 1.0.  We could also set goals now for 0.9.

I expect to be abundant of energy, :-) but I'll be spending much of it 
(or at least, much of my time) writing the submission and voting 
system.

> Having profiled CodeWarrior both with and without redundant include
> guards, I favor them, despite their unpleasant appearance.  I gather 
> that
> the latest CodeWarrior makes them unnecessary, but I also understand 
> that
> some people want to use Nitrogen with CW Pro 6!  And pragma once is a

"Some people"?  You mean there's more than one??

> gratuitously nonportable hack.  I'd like to keep Nitrogen pragma-free.

Will you make an exception for #pragma mark?

> I do think the nucleus needs to be pulled apart from Nitrogen.  It
> should be given its own namespace.  But that's a piece of work.

I don't think it's as bad as it sounds, at least not if the Carbon 
wrapper namespace is using the Nucleus namespace.

> (Any suggestions for the namespace name?  Nucleus?  NitrogenNucleus?
> NN for short?  Or N14?)

Have you already decided that the Carbon wrapper gets to keep the name 
Nitrogen?  What about Cyan or Cyanogen?  Speaking of which, I suggest 
that the forthcoming documentation include some clarification on what 
exactly these different names mean.  I've stopped using Cyan to refer 
to the adaptation rules since it doesn't appear in the code anywhere.

> I'm also leaning toward splitting some of the header files into two
> pieces -- Files_Types.h and Files.h, with only wrapper functions
> in the latter.  That should help with the lengths of compiles.

I'd still like to go further, but that would definitely help.

> I think we can make OSAIDs work with a data-carrying disposer.  And

The only problem with this approach is that routines such as OSAStore, 
OSAExecute, and OSADisplay need the OSAID and the ComponentInstance but 
don't accept ownership.  In other words, using my current code, they 
take a const ManagedOSAID&, not an Owned<ManagedOSAID>.  We can always 
require the user to pass the ComponentInstance as a separate parameter 
from the OSAID (as Carbon does), but I'd prefer to have the carrying of 
data be separable from ownership.  Perhaps Owned<OSAID> could yield a 
Managed<OSAID>.

template <>
struct Manager< OSAID >
{
	typedef ComponentInstance ManagerType;

	ComponentInstance Get() const;

	struct Disposer
	{
		Disposer( ComponentInstance );
		void operator( OSAID ) const;
	};
};

template <> struct Disposer< OSAID > : public Manager<OSAID>::Dispose  
{};

Owned<OSAID> foo = Owned<OSAID>::Seize( id, component );

Owned() would initialize its disposer (and indirectly the manager) with 
the component.

> I think that's the answer to disposing FSSpecs and FSRefs, which don't
> really have a null value.

A zero-filled FSSpec, though accepted by the File Manager as meaning 
the current default directory, is never returned by any Toolbox or 
Carbon routine, and could serve as a null value.

> See you at Adhoc!  And I'll try to have some new stuff by then.

Great!  I'm looking forward to it.

Josh

-- 
Joshua Juran
Metamage Software Creations - Mac Software and Consulting
http://www.metamage.com/

                * Creation at the highest state of the art *

Re: [Nitric-discuss] Next week

[Lisa L. <li...@wo...>]

Hi folks,

Sorry about being so hard to get to lately.  Moving is harder than I 
thought.

I'll just reply to various things in this thread at random:

I'd like to have a 0.9 release for the Adhoc CD, but I don't see a lot 
of
"making it happen" energy in my immediate future.  (I am hoping to have
enough to deal with some of the compatibility issues.)  And I agree we
should be shooting for a 1.0 release, but I can't imagine we could do
that for Adhoc.

Having profiled CodeWarrior both with and without redundant include
guards, I favor them, despite their unpleasant appearance.  I gather 
that
the latest CodeWarrior makes them unnecessary, but I also understand 
that
some people want to use Nitrogen with CW Pro 6!  And pragma once is a
gratuitously nonportable hack.  I'd like to keep Nitrogen pragma-free.

I do think the nucleus needs to be pulled apart from Nitrogen.  It
should be given its own namespace.  But that's a piece of work.
(Any suggestions for the namespace name?  Nucleus?  NitrogenNucleus?
NN for short?  Or N14?)

I'm also leaning toward splitting some of the header files into two
pieces -- Files_Types.h and Files.h, with only wrapper functions
in the latter.  That should help with the lengths of compiles.

I think we can make OSAIDs work with a data-carrying disposer.  And
I think that's the answer to disposing FSSpecs and FSRefs, which don't
really have a null value.

See you at Adhoc!  And I'll try to have some new stuff by then.

                                                       --Lisa

Re: [Nitric-discuss] Next week

[Joshua J. <wan...@me...>]

On Jul 13, 2004, at 11:32 AM, Marshall Clow wrote:

> Next week is AdHoc, and Joshua, Lisa and I will all be there.
>
> I think that we should make a list of things that we want to 
> accomplish, and work
> towards them.
>
> Some ideas:
>
> 1) A 1.0 release
> 	- What should it contain?
> 	- When should we release it?

I'm leading a Hands-On Nitrogen session, which will be our first major 
opportunity to collect user feedback.  I suggest that we consider 
attendees' comments before declaring anything final.

On the other hand, I think we should be prepared for some kind of 
release (be it 1.0, 0.9, or whatever) on the conference CD.

> 2) Holes to be filled
> 	- What managers need to be implemented before 1.0?
> 	- What are major "wants"?

MacTypes.cp needs to define the template functions generated for 
UniString by GNU libc.

> 3) Technical issues
> 	- What bothers you/confuses you about Nitrogen?

Indentation.  :-P

On a more serious note, I don't care for the redundant include guards.  
They're unsightly, a source of bugs, provide no benefit to runtime 
performance, capability, or code quality, and offer little improvement 
in compilation speed.  With gcc, they offer *zero* improvement in 
compilation speed, thanks to a preprocessor optimization.  I suggest 
that we'd be better off with #pragma once than redundant include 
guards[1], since CodeWarrior understands either.[2]

[1] However, we should absolutely retain the primary include guards.
[2] CodeWarrior Pro 6 sometimes ignores #pragma once, indicating that 
it's therefore no substitute for primary include guards.  But I have 
little interest in optimizing broken compilers.  Assuming the newer 
versions of CodeWarrior lack this misfeature, then #pragma once should 
provide the same benefit as redundant include guards, for less effort 
on out part.

> 	- What needs to be fixed/improved?
> 		- I have some issues/confusion about FlagTypes, for example.

The framework includes are broken, as I've said before.  I don't much 
care for the use of a macro in the include directive, either.  I 
suggest:

#include <TargetConditionals.h>
#if TARGET_RT_MAC_MACHO
	#include <Carbon/Carbon.h>  // or whatever frameworks are needed
#else
	#include <Quickdraw.h>  // or whichever headers are needed
#endif

Pseudoreference needs to be extended to deal with values requiring 
disposal, e.g. RgnHandle and AEDesc.  It needs to offer a conversion to 
const T& as well as Owned<T>.

I'd like to see a separation of Nitrogen's Nucleus from its Carbon 
support, at least in the file system, and possibly in regard to C++ 
namespaces as well.  I'm also concerned about the large size of some of 
the headers (e.g. Files.h), which has two effects:  Folders.h depends 
on (all of) Files.h, even though it only needs FSVolumeRefNum, and 
browsing or editing large headers is a nuisance.  We could split out 
the frequently used types (such as FSVolumeRefNum) and unwieldy classes 
(e.g. FSUserPrivileges) into their own headers 
(Nitrogen/Files/FSUserPrivileges.h), included from Files.h.

I don't mean to pick on Files.h, but... there's some 
pointer-to-member-function magic that CW Pro 6 just can't handle.  If 
we can agree on a preprocessor macro that disables the affected code, 
I'd be happy to supply it from my build management tool.

One other suggestion:  Define Maker<T> to return T().  That way, 
Make<Foo>() is defined as a zero-init for built-in types and a no-op 
for structs.  Then, have Owned<Foo> initialize its resource to 
Make<Foo>().  This leaves behavior for built-in types and structs with 
no Maker the same, but allows the user to define an initialized state 
for a struct such as FSSpec, FSRef, or AEDesc.  As long as a null value 
exists, (e.g. {typeNull,NULL} for AEDesc) we can use the 
NonDefaultValues liveliness test and don't need the seized flag.

Finally, there's got to be a better way to deal with OSAIDs than what I 
came up with.

> 4) Documentation
> 	- "The rules"
> 	- Coding standards
> 	- Developer-level docs

Some

> 5) Sample code

How about that poster child of Carbon porting, the traffic light 
sample?  And I have dibs on DropShell if Marshall passes.

> 6) Future directions
> 	- Poseven?

Huh?  Oh, POSIX++.  Cute.  I expect POSIX to be tougher to design 
Nitrogen rules for, but I also believe it's worth doing.

> 	- Classic support?

Pre-Carbon Mac Toolbox, on the other hand, the existing rules apply to 
quite nicely.  The only concessions needed within Nitrogen to support 
an otherwise external Nitrogen Classic project are user-defined classes 
to mimic the opaque CGrafPtr, WindowRef, and DialogRef, and 
conditionalizing the import of certain routines (e.g. 
"using::SelectWindow;" would have to be conditionalized for 
OPAQUE_TOOLBOX_STRUCTS).

> 	- Windows?

If someone volunteers to maintain it, I don't see why not.

> 7) Other items

T-shirts?

See you in just over a week!

Josh

-- 
Joshua Juran
Metamage Software Creations - Mac Software and Consulting
http://www.metamage.com/

                * Creation at the highest state of the art *

[Nitric-discuss] Next week

[Marshall C. <mar...@id...>]

Next week is AdHoc, and Joshua, Lisa and I will all be there.

I think that we should make a list of things that we want to 
accomplish, and work
towards them.

Some ideas:

1) A 1.0 release
	- What should it contain?
	- When should we release it?

2) Holes to be filled
	- What managers need to be implemented before 1.0?
	- What are major "wants"?

3) Technical issues
	- What bothers you/confuses you about Nitrogen?
	- What needs to be fixed/improved?
		- I have some issues/confusion about FlagTypes, for example.

4) Documentation
	- "The rules"
	- Coding standards
	- Developer-level docs

5) Sample code

6) Future directions
	- Poseven?
	- Classic support?
	- Windows?

7) Other items

Please help me fill these in......
-- 
-- Marshall

Marshall Clow     Idio Software   <mailto:mar...@id...>

It is by caffeine alone I set my mind in motion.
It is by the beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.