On Dec 27, 2007 8:39 PM, Johann MacDonagh <[EMAIL PROTECTED]> wrote:
> On 12/27/07, Bruce Markham <[EMAIL PROTECTED]> wrote:
> What you're saying is that after Assembly 1 was AOTed, and then
> Assembly 2 was AOTed, it would be impossible to change the class
> SomeType without having to re-AOT Assem
Johann MacDonagh wrote:
> On 12/27/07, Bruce Markham <[EMAIL PROTECTED]> wrote:
>
>> I know my brain is frazzled, which it is most nights at 3am, even when I
>> haven't been reading PCI specifications all day.
>>
>> But I do know, that if compile Assembly A with Generic Type 1. And Assembly
>> B
On 12/27/07, Bruce Markham <[EMAIL PROTECTED]> wrote:
> I know my brain is frazzled, which it is most nights at 3am, even when I
> haven't been reading PCI specifications all day.
>
> But I do know, that if compile Assembly A with Generic Type 1. And Assembly
> B with Normal Type 2 that uses Generi
Actually I planned to make it work by the end of next week, but
unfortunately some other stuff
came up so it will be delayed ... no idea for how long. Hopefully only
2-3 weeks.
Chriss.
Sander van Rossen wrote:
>> Creating a simple SEH should be easy, simply make a calling convention
>> that put
Sander van Rossen wrote:
> While working on the floppy controller driver code i noticed that
> there are so many error conditions it's not even funny anymore..
> Having exception handling would *really* help keeping the code clean...
> how easy/hard is it to implement exception handling support
Sander van Rossen wrote:
>> Creating a simple SEH should be easy, simply make a calling convention
>> that put the pointer to the exception on the stack. After every method
>> call look for that exception and catch/return.
>>
>
> Allright, then the next question is: how far along are we with
>
> Creating a simple SEH should be easy, simply make a calling convention
> that put the pointer to the exception on the stack. After every method
> call look for that exception and catch/return.
Allright, then the next question is: how far along are we with
implementing type information and object
Sander van Rossen wrote:
> On Dec 27, 2007 3:40 PM, Jonathan Chayce Dickinson
> <[EMAIL PROTECTED]> wrote:
>
> [...]
> Sorry, i wasn't clear.. i mean after we implemented object instancing
> etc. how hard would it be to implement exception handling?
>
>
Creating a simple SEH should be easy, s
On Dec 27, 2007 3:40 PM, Jonathan Chayce Dickinson
<[EMAIL PROTECTED]> wrote:
> Sander van Rossen wrote:
> > While working on the floppy controller driver code i noticed that
> > there are so many error conditions it's not even funny anymore..
> > Having exception handling would *really* help keepi
Sander van Rossen wrote:
> While working on the floppy controller driver code i noticed that
> there are so many error conditions it's not even funny anymore..
> Having exception handling would *really* help keeping the code clean...
> how easy/hard is it to implement exception handling support
While working on the floppy controller driver code i noticed that
there are so many error conditions it's not even funny anymore..
Having exception handling would *really* help keeping the code clean...
how easy/hard is it to implement exception handling support in the
AOT? (assuming that we ha
I used to using MonoDevelop. But now I'm also using the vim to editing :)
Seeing the MonoDevelop has changed a lot since I was using it, I'm gonna
check about the new features :)
On Dec 27, 2007 3:26 PM, Johann MacDonagh <[EMAIL PROTECTED]> wrote:
> I use vim for all my editing needs. However, i
On Dec 27, 2007 1:10 PM, Darx Kies <[EMAIL PROTECTED]> wrote:
> But I would suggest not to go that path but rather to use a Hardware
> Resource Manager.
ofcourse, i mentioned something like that before;
the tool that generates the code would write initialisation code, the
initialisation code would
I like the idea with the properties as well.
But I would suggest not to go that path but rather to use a Hardware
Resource Manager.
For example the VGA driver should not and needs not access the DMA or
ports that are
specific to query the PCI.
With the Hardware Resource Manager it would be eas
Sander van Rossen wrote:
> an usefull resource for naming pci vendor IDs:
>
>
Fun!!! The web is a great tool... First we need FS Access so that we can
load that file.
--
Jonathan Dickinson
an usefull resource for naming pci vendor IDs:
http://pciids.sourceforge.net/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/di
On Dec 27, 2007 8:34 AM, Bruce Markham <[EMAIL PROTECTED]> wrote:
> PCI configuration information is located by writing a UInt32 (a combination
> of bus, slot, device sub-function, and the index of the UInt16 you want to
> read from the config data), to port 0xCF8. And then the UInt16 that you
> ta
Sander van Rossen wrote:
> On Dec 27, 2007 7:31 AM, Jonathan Chayce Dickinson
> <[EMAIL PROTECTED]> wrote:
>
>> Can you get the disk driver working? I wan't to try plug ext2 into the
>> kernel.
>>
> We also need to think about kernel structure IMHO.
> Right now everything is almost a collec
> > > > Microsoft (and even Mono) both AOT core assemblies. (But if you
> apply my
> > > > generics comment, you'll know that even the AOTed assemblies, in
> both
> > cases,
> > > > still rely on a VES with JIT.) But there is no reason that our OSes
> GAC
> > > > won't have AOTed copies of installe
> So, I guess my question is, is there any tangible benefit to JIT
> compiling vs AOT compiling?
The only one i can think of is "on the fly profiling to make
applications run faster".. but then again, an AOTed application would
probably be faster to begin with...
There are some situations with co
On 12/27/07, Bruce Markham <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 27, 2007 2:40 AM, Johann MacDonagh <[EMAIL PROTECTED]> wrote:
> >
> > On 12/27/07, Bruce Markham <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > > Why is everyone so adamant about JIT compiling code? If you notice,
> > > > Microsoft th
On Dec 27, 2007 9:02 AM, Bruce Markham <[EMAIL PROTECTED]> wrote:
> I know my brain is frazzled, which it is most nights at 3am, even when I
> haven't been reading PCI specifications all day.
>
> But I do know, that if compile Assembly A with Generic Type 1. And Assembly
> B with Normal Type 2 that
I made a dumb disk controller. I can only detect what type of disk we
are dealing with:
--
Jonathan Dickinson
Index: ADC/FloppyDiskController.cs
===
--- ADC/FloppyDiskController.cs (revision 0)
+++ ADC/
I know my brain is frazzled, which it is most nights at 3am, even when I
haven't been reading PCI specifications all day.
But I do know, that if compile Assembly A with Generic Type 1. And Assembly
B with Normal Type 2 that uses Generic Type 1, it won't be able to
re-compile its own version of Gen
24 matches
Mail list logo
