I deleted the last events file, and then it loaded fine.
It happens on windows, I'll check it later on my linux box at home. I
closed the console window that was running the process. Other
important bit is that the state in the app must have been last
modified a couple of hourse before I closed the window. I can
reproduce it easily. Any thoughts?
Usually when this has happened to me it's because the data that was in
state changed. If you are using this as state:
data MyState = MyState Word16
And then decide that you need support for decimal numbers, you might
change it to this:
data MyState = MyState Double
The state system will try to read the binary representation for Word16
as if it were a Double. If you need to make a change like this, you
either need to delete your old state and start empty, or you need to
migrate your old data.
http://nhlab.blogspot.com/2008/12/data-migration-with-happs-data.html describes how to do a migration.
> too few bytes. Failed reading at byte position 25
> I deleted the last events file, and then it loaded fine.
> It happens on windows, I'll check it later on my linux box at home. I
> closed the console window that was running the process. Other
> important bit is that the state in the app must have been last
> modified a couple of hourse before I closed the window. I can
> reproduce it easily. Any thoughts?
On Thu, Jun 18, 2009 at 11:25 AM, MightyByte <mightyb...@gmail.com> wrote:
> Usually when this has happened to me it's because the data that was in
> state changed. If you are using this as state:
> data MyState = MyState Word16
> And then decide that you need support for decimal numbers, you might
> change it to this:
> data MyState = MyState Double
> The state system will try to read the binary representation for Word16
> as if it were a Double. If you need to make a change like this, you
> either need to delete your old state and start empty, or you need to
> migrate your old data.
> http://nhlab.blogspot.com/2008/12/data-migration-with-happs-data.html > describes how to do a migration.
> On Thu, Jun 18, 2009 at 1:40 PM, Kamil
> Dworakowski<ka...@dworakowski.name> wrote:
> > the error on start:
> > too few bytes. Failed reading at byte position 25
> > I deleted the last events file, and then it loaded fine.
> > It happens on windows, I'll check it later on my linux box at home. I
> > closed the console window that was running the process. Other
> > important bit is that the state in the app must have been last
> > modified a couple of hourse before I closed the window. I can
> > reproduce it easily. Any thoughts?
On Jun 18, 7:25 pm, MightyByte <mightyb...@gmail.com> wrote:
> Usually when this has happened to me it's because the data that was in
> state changed.
Messing with types produced me:
apprazor: Junk after checkpoint for state: Main.State
This does not mean that the msg I got on windows can not be an effect
of a an unmigrated state. I am pretty sure the types were fine though.
I'll check it one more time tomorrow. OTOH, I could not get it to fail
like this on Linux, which is a good news.
BTW, when I changed type of one of the fields from string to double to
check how happstack would fail ... it did not. It interpreted all the
strings as 0.0.
Yes, dcoutts and I were discussing this exact issue on #happs earlier
today. Errors from lack of migration show up at runtime and laziness
means that they don't always happen when state is loaded on startup.
Sometimes it runs fine until the offending data is used.
To fix this, we would probably need to embed some kind of
self-describing meta-data in the stored data. I actually just wrote
my first migration for a production site today. I haven't deployed it
yet, but these issues definitely cause for some worry. In my opinion
this should probably be a pretty high priority.
> On Jun 18, 7:25 pm, MightyByte <mightyb...@gmail.com> wrote:
>> Usually when this has happened to me it's because the data that was in
>> state changed.
> Messing with types produced me:
> apprazor: Junk after checkpoint for state: Main.State
> This does not mean that the msg I got on windows can not be an effect
> of a an unmigrated state. I am pretty sure the types were fine though.
> I'll check it one more time tomorrow. OTOH, I could not get it to fail
> like this on Linux, which is a good news.
> BTW, when I changed type of one of the fields from string to double to
> check how happstack would fail ... it did not. It interpreted all the
> strings as 0.0.
> too few bytes. Failed reading at byte position 25
> I deleted the last events file, and then it loaded fine.
> It happens on windows, I'll check it later on my linux box at home. I
> closed the console window that was running the process. Other
> important bit is that the state in the app must have been last
> modified a couple of hourse before I closed the window. I can
> reproduce it easily. Any thoughts?
> On Jun 18, 8:40 pm, Kamil Dworakowski <ka...@dworakowski.name> wrote:
> > the error on start:
> > too few bytes. Failed reading at byte position 25
> > I deleted the last events file, and then it loaded fine.
> > It happens on windows, I'll check it later on my linux box at home. I
> > closed the console window that was running the process. Other
> > important bit is that the state in the app must have been last
> > modified a couple of hourse before I closed the window. I can
> > reproduce it easily. Any thoughts?
>> On Jun 18, 8:40 pm, Kamil Dworakowski <ka...@dworakowski.name> wrote:
>> > the error on start:
>> > too few bytes. Failed reading at byte position 25
>> > I deleted the last events file, and then it loaded fine.
>> > It happens on windows, I'll check it later on my linux box at home. I
>> > closed the console window that was running the process. Other
>> > important bit is that the state in the app must have been last
>> > modified a couple of hourse before I closed the window. I can
>> > reproduce it easily. Any thoughts?
Would a solution to the laziness issue be one where HAppS attempts to
write the checkpoint to /dev/null at startup?
-Alex-
On 6/18/09 4:05 PM, MightyByte wrote:
Yes, dcoutts and I were discussing this exact issue on #happs earlier
today. Errors from lack of migration show up at runtime and laziness
means that they don't always happen when state is loaded on startup.
Sometimes it runs fine until the offending data is used.
To fix this, we would probably need to embed some kind of
self-describing meta-data in the stored data. I actually just wrote
my first migration for a production site today. I haven't deployed it
yet, but these issues definitely cause for some worry. In my opinion
this should probably be a pretty high priority.
On Thu, Jun 18, 2009 at 3:33 PM, Kamil
Dworakowski<kamil@dworakowski.name> wrote:
Usually when this has happened to me it's because the data that was in
state changed.
Messing with types produced me:
apprazor: Junk after checkpoint for state: Main.State
This does not mean that the msg I got on windows can not be an effect
of a an unmigrated state. I am pretty sure the types were fine though.
I'll check it one more time tomorrow. OTOH, I could not get it to fail
like this on Linux, which is a good news.
BTW, when I changed type of one of the fields from string to double to
check how happstack would fail ... it did not. It interpreted all the
strings as 0.0.
Possibly. It would make failures more reliable, which would help, but
it wouldn't solve the problem of data format changes where the size of
a changed data item is invariant (i.e. changing a Word32 to four
Word8s). The general solution is to include the schema (or possibly a
hash of the schema) as metadata that is part of the serialized data.
Something like Java's serialVersionUID (brief description towards the
end of http://java.sun.com/developer/technicalArticles/Programming/serializa...)
might be a suitable solution to this problem.
On Fri, Jun 19, 2009 at 6:38 AM, Alex Jacobson<a...@alexjacobson.com> wrote:
> Would a solution to the laziness issue be one where HAppS attempts to write
> the checkpoint to /dev/null at startup?
> -Alex-
> On 6/18/09 4:05 PM, MightyByte wrote:
> Yes, dcoutts and I were discussing this exact issue on #happs earlier
> today. Errors from lack of migration show up at runtime and laziness
> means that they don't always happen when state is loaded on startup.
> Sometimes it runs fine until the offending data is used.
> To fix this, we would probably need to embed some kind of
> self-describing meta-data in the stored data. I actually just wrote
> my first migration for a production site today. I haven't deployed it
> yet, but these issues definitely cause for some worry. In my opinion
> this should probably be a pretty high priority.
> On Thu, Jun 18, 2009 at 3:33 PM, Kamil
> Dworakowski<ka...@dworakowski.name> wrote:
> On Jun 18, 7:25 pm, MightyByte <mightyb...@gmail.com> wrote:
> Usually when this has happened to me it's because the data that was in
> state changed.
> Messing with types produced me:
> apprazor: Junk after checkpoint for state: Main.State
> This does not mean that the msg I got on windows can not be an effect
> of a an unmigrated state. I am pretty sure the types were fine though.
> I'll check it one more time tomorrow. OTOH, I could not get it to fail
> like this on Linux, which is a good news.
> BTW, when I changed type of one of the fields from string to double to
> check how happstack would fail ... it did not. It interpreted all the
> strings as 0.0.
> >> On Jun 18, 8:40 pm, Kamil Dworakowski <ka...@dworakowski.name> wrote:
> >> > the error on start:
> >> > too few bytes. Failed reading at byte position 25
> >> > I deleted the last events file, and then it loaded fine.
> >> > It happens on windows, I'll check it later on my linux box at home. I
> >> > closed the console window that was running the process. Other
> >> > important bit is that the state in the app must have been last
> >> > modified a couple of hourse before I closed the window. I can
> >> > reproduce it easily. Any thoughts?
On Mon, Jun 29, 2009 at 4:48 PM, Matthew Elder<sse...@gmail.com> wrote:
> Can we get a confirmation that this fixes the behavior against the
> 0.3.2 tag? I will release a 0.3.3 when I can get a confirmation (with
> this patch).
> On Jun 19, 2:47 am, Kamil Dworakowski <ka...@dworakowski.name> wrote:
>> Here comes a patch for the happstack repo.
>> On Fri, Jun 19, 2009 at 10:42 AM, KamilDworakowski<ka...@dworakowski.name> wrote:
>> > I confirm that. Applying the patch provided by awson fixes it.
>> >> On Jun 18, 8:40 pm, Kamil Dworakowski <ka...@dworakowski.name> wrote:
>> >> > the error on start:
>> >> > too few bytes. Failed reading at byte position 25
>> >> > I deleted the last events file, and then it loaded fine.
>> >> > It happens on windows, I'll check it later on my linux box at home. I
>> >> > closed the console window that was running the process. Other
>> >> > important bit is that the state in the app must have been last
>> >> > modified a couple of hourse before I closed the window. I can
>> >> > reproduce it easily. Any thoughts?
> On Mon, Jun 29, 2009 at 4:48 PM, Matthew Elder<sse...@gmail.com> wrote:
>> Can we get a confirmation that this fixes the behavior against the
>> 0.3.2 tag? I will release a 0.3.3 when I can get a confirmation (with
>> this patch).
>> On Jun 19, 2:47 am, Kamil Dworakowski <ka...@dworakowski.name> wrote:
>>> Here comes a patch for the happstack repo.
>>> On Fri, Jun 19, 2009 at 10:42 AM,
>>> KamilDworakowski<ka...@dworakowski.name> wrote:
>>> > I confirm that. Applying the patch provided by awson fixes it.
>>> >> On Jun 18, 8:40 pm, Kamil Dworakowski <ka...@dworakowski.name> wrote:
>>> >> > the error on start:
>>> >> > too few bytes. Failed reading at byte position 25
>>> >> > I deleted the last events file, and then it loaded fine.
>>> >> > It happens on windows, I'll check it later on my linux box at home.
>>> >> > I
>>> >> > closed the console window that was running the process. Other
>>> >> > important bit is that the state in the app must have been last
>>> >> > modified a couple of hourse before I closed the window. I can
>>> >> > reproduce it easily. Any thoughts?
On Tue, Jun 30, 2009 at 4:41 PM, Matthew Elder<m...@mattelder.org> wrote:
> Did you test it?
> On 6/29/09, Kamil Dworakowski <ka...@dworakowski.name> wrote:
>> yep, it is a good fix afaik
>> On Mon, Jun 29, 2009 at 4:48 PM, Matthew Elder<sse...@gmail.com> wrote:
>>> Can we get a confirmation that this fixes the behavior against the
>>> 0.3.2 tag? I will release a 0.3.3 when I can get a confirmation (with
>>> this patch).
>>> On Jun 19, 2:47 am, Kamil Dworakowski <ka...@dworakowski.name> wrote:
>>>> Here comes a patch for the happstack repo.
>>>> On Fri, Jun 19, 2009 at 10:42 AM,
>>>> KamilDworakowski<ka...@dworakowski.name> wrote:
>>>> > I confirm that. Applying the patch provided by awson fixes it.
>>>> >> On Jun 18, 8:40 pm, Kamil Dworakowski <ka...@dworakowski.name> wrote:
>>>> >> > the error on start:
>>>> >> > too few bytes. Failed reading at byte position 25
>>>> >> > I deleted the last events file, and then it loaded fine.
>>>> >> > It happens on windows, I'll check it later on my linux box at home.
>>>> >> > I
>>>> >> > closed the console window that was running the process. Other
>>>> >> > important bit is that the state in the app must have been last
>>>> >> > modified a couple of hourse before I closed the window. I can
>>>> >> > reproduce it easily. Any thoughts?
There is a possibility that we may release independent updates to each
cabal package as opposed to bumping everythying up. Esp in the case of
maintenance / bugfix version releases.
On 6/30/09, Kamil Dworakowski <ka...@dworakowski.name> wrote:
> BTW why do you create tags for happstack-{server,state,...}-version
> instead of just happstack-version?
> On Tue, Jun 30, 2009 at 4:41 PM, Matthew Elder<m...@mattelder.org> wrote:
>> Did you test it?
>> On 6/29/09, Kamil Dworakowski <ka...@dworakowski.name> wrote:
>>> yep, it is a good fix afaik
>>> On Mon, Jun 29, 2009 at 4:48 PM, Matthew Elder<sse...@gmail.com> wrote:
>>>> Can we get a confirmation that this fixes the behavior against the
>>>> 0.3.2 tag? I will release a 0.3.3 when I can get a confirmation (with
>>>> this patch).
>>>> On Jun 19, 2:47 am, Kamil Dworakowski <ka...@dworakowski.name> wrote:
>>>>> Here comes a patch for the happstack repo.
>>>>> On Fri, Jun 19, 2009 at 10:42 AM,
>>>>> KamilDworakowski<ka...@dworakowski.name> wrote:
>>>>> > I confirm that. Applying the patch provided by awson fixes it.
>>>>> >> On Jun 18, 8:40 pm, Kamil Dworakowski <ka...@dworakowski.name>
>>>>> >> wrote:
>>>>> >> > the error on start:
>>>>> >> > too few bytes. Failed reading at byte position 25
>>>>> >> > I deleted the last events file, and then it loaded fine.
>>>>> >> > It happens on windows, I'll check it later on my linux box at
>>>>> >> > home.
>>>>> >> > I
>>>>> >> > closed the console window that was running the process. Other
>>>>> >> > important bit is that the state in the app must have been last
>>>>> >> > modified a couple of hourse before I closed the window. I can
>>>>> >> > reproduce it easily. Any thoughts?
> >> On Jun 18, 8:40 pm, Kamil Dworakowski <ka...@dworakowski.name> wrote:
> >> > the error on start:
> >> > too few bytes. Failed reading at byte position 25
> >> > I deleted the last events file, and then it loaded fine.
> >> > It happens on windows, I'll check it later on my linux box at home. I
> >> > closed the console window that was running the process. Other
> >> > important bit is that the state in the app must have been last
> >> > modified a couple of hourse before I closed the window. I can
> >> > reproduce it easily. Any thoughts?
