@thread

Does anyone know who actually owns the Envoy product?


Thanks

@ChrisH

Wow this looks like a great utility!

Of course I have a couple of suggestions for the current viewing model:

- use some sort of "treeview" style which summarizes by day/week/month (via options)
- you can then open a particular day or week or month to see the changes from that period

In addition, it would be nice if this could be integrated into the installation system somehow. This would enable creating a "named" install (i.e. "Firefox 4.01") and provide for a generic uninstall solution.

This is a follow-up to a thread here:

http://www.os4coding.net/forum/improving-quality-software-releases

Cheers!
Greg

Any updates on Torque engine?

@Shadow -

Thanks for the info. Item on my watchlist...

@thread

All these different ways to check for the O/S version don't sound all that consistent to me.

IMO there should be a function call on an interface somewhere (IExec?) called GetOSVersion.

It could return something like the following:
- public version number string (i.e. "4.1.1")
- major version (4)
- minor version (1)
- service pack/maint release number (1)

I use a win32 API call named "GetVersionEx" and it gives back similar information.

Having to decode library versions seems a bit hack-ish.

I see from your listing this is an "unfixed" board.

Can someone recap for me what the restrictions are with the board in this state?

Is a PCI NIC mandatory? PCI USB?


Thanks

First press release is out and it's looking good!

Link: Freescale Drives Embedded Multicore Innovation with New QorIQ Advanced Multiprocessing Series

In summary:
- announces new E6500 64bit core
- multithreaded (2 threads per core)
- up to 2.5Ghz clock rate
- 28nm process
- Altivec
- first chip is 12 core/24thread beast, T4240
- availability "early 2012" - typical Freescale

Looks like a good next-generation candidate for the X1000 series. By the time these are mature the timing should be about right.

Quoting directly from press release:

The AMP series consists of three levels of products within a scalable portfolio, initially spanning from ultra-high-performance processors featuring 24 virtual cores down to single-core products.

Control plane processors (service provider routers, storage networks)
Up to 6 cores running at up to 2.5 GHz
Greater than 6 MB L2 cache

High-end data plane processors (routers, switches, access gateways, mil/aero applications)
Up to 24 virtual cores running at up to 2.0 GHz
50 Gbps IP forwarding capability
Advanced application acceleration

Low-end data plane processors (media gateways, network attached storage, integrated services router) Up to 8 virtual cores running up to 1.6 GHz
Advanced application acceleration
Less than 10W power

Freescale's first product in the QorIQ AMP series, the T4240 device, integrates a host of hardware accelerators with 12 dual-threaded e6500 cores, providing 24 threads to address high-end data plane processing applications. Dual-threaded efficiency, improved DMIPs per thread and higher frequency deliver 4x performance gain and more than 2x power efficiency gain over the previous-generation QorIQ P4080 device. Advanced capabilities allow for intelligent sharing and duplication of resources between threads and a larger amount of on-die cache per core. Application examples for the T4240 device include metro carrier edge routers, access gateways and aerospace/defense products. Freescale will provide more details regarding the T4240 product later this year. The device is planned for initial availability in early 2012.

Nice work.

That "flexible CPU riser" is a bit scary, but at the low clock rates involved I guess you are OK.

I bet that was a lot of fun to put together.

Not going but hoping they announce some new PPC products!

@alfkil

May I suggest you provide more detail on your QT speed issue?

Someone else may have an idea for you given the issue you are facing.

@Phantom

It would make sense to work on integrating with one or more of the current IDE in progress:
- Codebench
- AVD
- others?

No point splitting the IDE market futher IMO. Rather work on making the Amidark engine better. Don't spread yourself too thin.

@Snuffy

Quote:
The built-in video is on a 66Mhz, 32 bit bus. That works out to a maximum of 264MB/second. Sounds like the write speed is hitting the bus limit. Can't do much better than that!

@kolla

Quote:[/quote]
The suggestions are for situations where there is no execute or script bit set. The file is an 'unknown'. If the datatype is flagged as an executable then there is nothing left to decide.

*Perhaps* in the future the system *could* be made smarter to recognize an executable and run it without the need for the "execute" bit.

What triggered my initial comments was the thought of adding more attribute bits to the file that tag it with the script flavour, be it classic script, or some new script engine. That is entirely the wrong direction IMO. This is where the data types could be used to determine if the file is a script and which interpreter is required.

Quote:
New users would find it equally annoying to deal with elitist attitutes.

Quote:
"Ignorants" are first time users. You were one at one point. People don't buy a computer for the O/S, they buy it for what it can do for them. As much as possible the O/S should get out of the way and just do the right thing.

I believe that power users would find a system smart enough to recognize new types of scripts via the data type system to be quite smart and not a detraction as you posit. You may even find it useful for other reasons.

In the big scheme of things this isn't a huge issue, but if the system can be made "smarter" then why not at least entertain the idea?

Hi vidarh -

If a script is missing the execute bit, the determination of its executable status would come from datatypes looking at:
- the file extension (i.e. .rx, .rexx, .py, .r)
- a magic file first-line header (such as the /* COMMENT */ tag used by Arexx)

If a script file does not have a matching file extension or first-line header then it will not be considered a script.

To recap, I am not advocating for the removal of the execute bit. What I am advocating for is not relying on this bit for every script and binary ever loaded onto a user's machine.

Even if you do set an executable bit for a script the interpreter must still be determined. Back to datatypes again, anyway. As a bonus deficons could work for scripts in workbench.

And apologies if I am throwing this thread off-topic, but this issue has struck a nerve.

@emeck

You are close. I see no need to set a script/executable bit.

If it is a script and the datatype system is set up correctly as you say the scripts would be recognized by extension or content.

@kolla

The datatypes would be flagged as executable, obviously.

My suggestions are aimed squarely at making the system less "stupid" and "just work" for the average user out there, not the typical power users that inhabit these boards.

If we ever want to grow a userbase the operating system has to be improved to deal with some of its quirks. In my opinion, needing to set a special executable bit (or even more "special" executable bits suggested above) which often get messed up by archivers and other tools is a bad design.

@xenic

Forgive me for being a bit overly-explanatorial but let me brain-dump somewhat...

On Windows, there is no execute bit you need to set. The operating system looks at the file extensions specified in the PATHEXT environment variable. It makes things easier for the user but forces regular binaries to have a .exe extension and is rather brain-dead.

On OS4 we have the datatype system. Perhaps the method of determining if a file is executable should be looking to that? Perhaps the protection bits could also be used to mark a file as NOT executable?

In other words, executable bits could flag as file as:
- executable
- not executable
- unknown (fall back to datatypes)

The trick is determining what script files are executable. I am guessing the order could be:
- look at executable flag
- look to datatypes (file extension)
- look to datatypes (file content - i.e. something like "#!/bin/sh" on UNIX)

Here are my thoughts on the "is this file executable" logic:

1. Is the file tagged as NOT executable? Ignore it
2. Is the file tagged as executable? Run it. Look to datatypes for how to run, i.e. if a script which interpreter.
3. Test via datatypes:
- executable binary?
- executable script?

@abalaban/centaurz

I don't code for OS4 at the moment so my suggestion was totally out of left field.

Sometimes there is no good solution but if there was a way to make the control more robust then there is an opportunity for improvement.

Cheers!

P.S. I work with the win32 listview control extensively so I know what fun these things can be to get working the way you want.

@trixie

One of the things that Windows has is a "GetLastError" function for calls that don't really have a good way of returning an error code.

Perhaps something like this could exist for some of the calls into ReAction? For example, if a control creation/function fails, there would be some sort of call to get more diagnostic information. Even better if this could log in debug mode.

@alfkil

Niggly. Second sizeof(DATA1) should be DATA2.