// Create an instance of StreamReader to read from a file. // The using statement also closes the StreamReader. using (StreamReader sr = new StreamReader("TestFile.txt")) { String line; // Read and display lines from the file until the end of // the file is reached. while ((line = sr.ReadLine()) != null) { Console.WriteLine(line); } }Link
Netduino Firmware v4.2.0 BETA 1
#61
Posted 05 July 2011 - 05:09 AM
#62
Posted 05 July 2011 - 05:23 AM
#63
Posted 05 July 2011 - 07:44 AM
Hmm. Thanks for the details. Very interesting.
Two questions:
1. Does ColinR's sample work as a workaround?
2. Does your example work with files on Windows (i.e. is the behavior inconsistent between .NET and .NET MF)?
Chris
Very interesting. I wonder if that has become the recommended way to check for EndOfStream? If you search you'll find that a lot of people give examples they way I use EndOfStream. I managed to find one official example as well: http://msdn.microsof...y/ee461504.aspx (step 9).
Answers:-
2. This design pattern does work in the standard framework as I use it quite often.
1. Interesting, this pattern manages to read all the lines, but doesn't stop trying to read lines when the EndOfStream is hit:-
Debug.Print(File.Exists(filename) ? "File Found" : "File Not Found!"); using (StreamReader sr = new StreamReader(filename)) { Debug.Print("Initial EOS:" + sr.EndOfStream.ToString()); String line; // Read and display lines from the file until the end of // the file is reached. while ((line = sr.ReadLine()) != null) { Debug.Print("LINE:" + line + " - EOS:" + sr.EndOfStream.ToString()); } }
This gived me the following output...
File Found
Initial EOS:True
LINE:TestLine0 - EOS:False
LINE:TestLine1 - EOS:False
LINE:TestLine2 - EOS:False
LINE:TestLine3 - EOS:False
LINE:TestLine4 - EOS:True
LINE: - EOS:True
LINE: - EOS:True
LINE: - EOS:True
...
So it looks like EndOfStream isn't set until the first line is read.
If I step over the code, "line" is never set to null, if there's no data available it seems to be set to empty string. I wouldn't be happy to use this to determin the end of file.
It looks like I can get what I want by using a mix of this approach and adding a check for EndOfStream within the loop, like this:-
using (StreamReader sr = new StreamReader(filename)) { Debug.Print("Initial EOS:" + sr.EndOfStream.ToString()); String line; // Read and display lines from the file until the end of // the file is reached. while ((line = sr.ReadLine()) != null) { Debug.Print("LINE:" + line + " - EOS:" + sr.EndOfStream.ToString()); if (sr.EndOfStream) break; } }
Tim
#65
Posted 05 July 2011 - 10:13 AM
Not FAT file access count - in a previous thread (that I can't now find) relating to out of memory issues you'd said you were going to reduce both the number and size of buffers allocated by the FAT file system. You also said in that thread you were going to change the wording of the GC message "Failed to allocate..." to clarify that it was a compaction trigger rather than an out of memory situation. The old wording remains so I wondered if the memory tuning got done and whether all this is in 4.2.We build the tuning down of buffer sizes into the v4.1.0.0 firmware, and it's now included in the v4.2 firmware as well.
What is the FAT file access count memory issue? If that has been changed in the 4.2 codebase, it's included as well.
The GC bugfixes are included for sure.
We'll be posting v4.2 beta 2 later this weekend, now with "WithEvents" support for VB programmers.
Chris
Thanks for clearsing this up.
Edward
#66
Posted 05 July 2011 - 10:37 AM
#67
Posted 05 July 2011 - 02:12 PM
We changed this in an early version of 4.1.0...so all current versions should have the reduced FAT buffers and updated wording. This should all be checked in with the .NET MF 4.2 beta 1+ firmware as well.Not FAT file access count - in a previous thread (that I can't now find) relating to out of memory issues you'd said you were going to reduce both the number and size of buffers allocated by the FAT file system. You also said in that thread you were going to change the wording of the GC message "Failed to allocate..." to clarify that it was a compaction trigger rather than an out of memory situation. The old wording remains so I wondered if the memory tuning got done and whether all this is in 4.2.
Chris
#68
Posted 05 July 2011 - 02:14 PM
The OneWire support is an add-on. We'll make a version with OneWire when the beta gets farther along (release candidate or RTM). I believe that CW2 is working on some updates, so we'll be sure to include the latest version.Does this beta include the OneWire support by CW2?
When you reboot the Netduino, are you able to connect? Could you run "Target -> Device Capabilities" and post the results here?Since updating i can no longer deploy to my Netduino... I just sticks at deploying...
Chris
#69
Posted 14 July 2011 - 10:17 PM
Exception was thrown: System.Exception: System.Version::ToStringWhen using:
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString()
Exception was thrown: System.Exception: Microsoft.SPOT.Net.NetworkInformation.NetworkInterface::get_DnsAddressesWhen using:
ni.DnsAddresses[0]
Exception was thrown: System.Exception: Microsoft.SPOT.Net.NetworkInformation.NetworkInterface::IPAddressToString Microsoft.SPOT.Net.NetworkInformation.NetworkInterface::get_DnsAddressesWhen using:
ni.DnsAddresses[0]
#70
Posted 14 July 2011 - 10:35 PM
#71
Posted 15 July 2011 - 05:14 AM
Colin,
Did you set your network settings in MFDeploy after flashing the .NET MF 4.2 beta?
Chris
I did, yes. What I didn't do is update the tinybooter - the 4.2 beta looked like it flashed ok though?
The exceptions do not hit every time unfortunately - I can't see a pattern.
#72
Posted 15 July 2011 - 05:31 AM
#73
Posted 15 July 2011 - 06:39 AM
Could you please update TinyBooter as well and re-test? That could actually be important here...
Chris
OK, will update it tonight and re-post.
#74
Posted 15 July 2011 - 08:11 PM
#75
Posted 16 July 2011 - 02:27 PM
I agree, but I'm not an expert of things and like we say in Dutch: "van 't kastje naar de muur". Litteraly: "from the cupboard to the wall" but loosly translated being bounced around.
So perhaps you could reply on that issue, or take some other actions? If you need me to test anything, you know how to contact me
The hang on deployment and the following BSOD on disconnect or reset is driving me crazy; makes serious development an absolute pain. It's happening to me on about 50% of deployments. Is there any known workaround? Is the 4.1 driver better than the 4.2? Is it happening only to a few people or everybody? Only 4 votes on codeplex. I'm using Win7 64bit and VS2010 Pro.
Edward
#76
Posted 17 July 2011 - 10:12 PM
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#77
Posted 30 July 2011 - 02:00 PM
It's happening to me. Win7 32bit, VS2010 Express. I'm now the 8th vote on CodePlex.The hang on deployment and the following BSOD on disconnect or reset is driving me crazy
...
Is it happening only to a few people or everybody? Only 4 votes on codeplex. I'm using Win7 64bit and VS2010 Pro.
Edward
So weird to see the BSOD. It's been years.
#78
Posted 30 July 2011 - 04:13 PM
I had it happen a couple times yesterday after going to 4.2 as well.It's happening to me. Win7 32bit, VS2010 Express. I'm now the 8th vote on CodePlex.
So weird to see the BSOD. It's been years.
#79
Posted 04 August 2011 - 11:52 PM
I had it happen a couple times yesterday after going to 4.2 as well.
I just spotted that this issue despite a high vote count was closed on Codeplex this Monday by "lorenzte" with no explanation. Outrageous.
Seriously considering an alternative platform for my product development as NETMF is proving too painful and unproductive at the moment. I had high hopes for it.
:-/
#80
Posted 05 August 2011 - 12:41 AM
I believe he closed the blue screen issue with a note that it may be fixed in RC1 (and to re-open it if it's not).I just spotted that this issue despite a high vote count was closed on Codeplex this Monday by "lorenzte" with no explanation. Outrageous.
Can you downloaded the brand new .NET MF 4.2 RC1 SDK and see if you still get the issue (and if so, we'll push to re-open the issue)?
Chris
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users