Feature request: CharSequence instead of Strings for parsing…

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Feature request: CharSequence instead of Strings for parsing…

Viktor Hedefalk
Hi,

I'm trying to use joda-time from within a Scala parser-combinator. I'm
writing a parser for the output of a command line interface and as
part of this I need to parse some dates. I would really like to use
joda-time for this since I really don't want to reinvent the wheel.
There is however an impedance mismatch since the combinator-parser
library traverses CharSequences and the joda-time api wants Strings as
input. The combinator parsers are stream-based so there is really no
chance they could work on Strings.

Scala's combinator-parsers are a really nifty piece of software since
it allows me to write really concise production-rules for my grammar,
but I couldn't find any established way to parse dates from standard
patterns. The basic building blocks are mostly just regex, but it's
very easy to combine these into more advanced parsers. And it is also
very easy to write your own custom parsers, but they have to work on
CharSequences.

Basically, what I wanted to do was just to wrap the
dateFormat.parseInto()-method in a Scala-parser to be able to use it
as a building-block for other parsers.

When looking at the joda-time source, I could not really find any real
reason why it had to work with Strings. So I made an attempt to change
it to work with CharSequences instead. I cloned the unofficial mirror
over at github and made my changes. The output of this is over here:

https://github.com/hedefalk/joda-time/commit/ef3bdafd89b334fb052ce0dd192613683b3486a4

It was quick and dirty but less than an hour of work. Risking that
this email turns long, It allows me to write a Scala-parser like this

trait DateParsers extends RegexParsers {
  def dateTime(pattern: String): Parser[DateTime] = new Parser[DateTime] {
    val dateFormat = DateTimeFormat.forPattern(pattern);

    def jodaParse(text: CharSequence, offset: Int) = {
      val mutableDateTime = new MutableDateTime
      val newPos = dateFormat.parseInto(mutableDateTime, text, offset);
      (mutableDateTime.toDateTime, newPos)
    }

    def apply(in: Input) = {
      val source = in.source
      val offset = in.offset
      val start = handleWhiteSpace(source, offset)
      val (dateTime, endPos) = jodaParse(source, start)
      if (endPos >= 0)
        Success(dateTime, in.drop(endPos - offset))
      else
        Failure("Failed to parse date", in.drop(start - offset))
    }
  }
}

which can then be used in production rules like this:


def changeset: Parser[ChangeSet] = changesetIdRow ~ opt(tagRow) ~
userRow ~ dateRow ~ summaryRow ^^
    {
      case changesetIdVal ~ tagOption ~ userVal ~ dateVal ~ summaryVal =>
        new ChangeSet(changesetIdVal, tagOption, userVal, dateVal, summaryVal)
    }

  private[this] def changesetIdRow = "changeset:" ~> changesetId
  private[this] def tagRow = "tag:" ~> ".*".r
  private[this] def userRow = "user:" ~> ".*".r
  private[this] def dateRow = "date:" ~> dateTime("EEE MMM d HH:mm:ss yyyy Z")
  private[this] def summaryRow = "summary:" ~> ".*".r


Anyway, I just wanted to show that this would be really useful for me.
By simply making joda-time parse CharSequences instead of Strings it
becomes a lot easier to use as part of a stream-based
parsing-framework.

Would it be possible to make a change like this to joda-time? As I
said, the patch linked above is just a quick and dirty fix, but I
wanted to see that it worked. All tests pass and the only thing that
really had to be replaced was the regionMatches()-method on String.

Cheers,
Viktor

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

jodastephen
I agree that Joda-Time should parse CharSequence. However, it also has
to remain backwards compatible, and that tends to limit the changes
that can be made. I will keep this email starred to see if there is
anything I can do before releasing v2.0.

Stephen


On 3 February 2011 14:19, Viktor Hedefalk <[hidden email]> wrote:

> Hi,
>
> I'm trying to use joda-time from within a Scala parser-combinator. I'm
> writing a parser for the output of a command line interface and as
> part of this I need to parse some dates. I would really like to use
> joda-time for this since I really don't want to reinvent the wheel.
> There is however an impedance mismatch since the combinator-parser
> library traverses CharSequences and the joda-time api wants Strings as
> input. The combinator parsers are stream-based so there is really no
> chance they could work on Strings.
>
> Scala's combinator-parsers are a really nifty piece of software since
> it allows me to write really concise production-rules for my grammar,
> but I couldn't find any established way to parse dates from standard
> patterns. The basic building blocks are mostly just regex, but it's
> very easy to combine these into more advanced parsers. And it is also
> very easy to write your own custom parsers, but they have to work on
> CharSequences.
>
> Basically, what I wanted to do was just to wrap the
> dateFormat.parseInto()-method in a Scala-parser to be able to use it
> as a building-block for other parsers.
>
> When looking at the joda-time source, I could not really find any real
> reason why it had to work with Strings. So I made an attempt to change
> it to work with CharSequences instead. I cloned the unofficial mirror
> over at github and made my changes. The output of this is over here:
>
> https://github.com/hedefalk/joda-time/commit/ef3bdafd89b334fb052ce0dd192613683b3486a4
>
> It was quick and dirty but less than an hour of work. Risking that
> this email turns long, It allows me to write a Scala-parser like this
>
> trait DateParsers extends RegexParsers {
>  def dateTime(pattern: String): Parser[DateTime] = new Parser[DateTime] {
>    val dateFormat = DateTimeFormat.forPattern(pattern);
>
>    def jodaParse(text: CharSequence, offset: Int) = {
>      val mutableDateTime = new MutableDateTime
>      val newPos = dateFormat.parseInto(mutableDateTime, text, offset);
>      (mutableDateTime.toDateTime, newPos)
>    }
>
>    def apply(in: Input) = {
>      val source = in.source
>      val offset = in.offset
>      val start = handleWhiteSpace(source, offset)
>      val (dateTime, endPos) = jodaParse(source, start)
>      if (endPos >= 0)
>        Success(dateTime, in.drop(endPos - offset))
>      else
>        Failure("Failed to parse date", in.drop(start - offset))
>    }
>  }
> }
>
> which can then be used in production rules like this:
>
>
> def changeset: Parser[ChangeSet] = changesetIdRow ~ opt(tagRow) ~
> userRow ~ dateRow ~ summaryRow ^^
>    {
>      case changesetIdVal ~ tagOption ~ userVal ~ dateVal ~ summaryVal =>
>        new ChangeSet(changesetIdVal, tagOption, userVal, dateVal, summaryVal)
>    }
>
>  private[this] def changesetIdRow = "changeset:" ~> changesetId
>  private[this] def tagRow = "tag:" ~> ".*".r
>  private[this] def userRow = "user:" ~> ".*".r
>  private[this] def dateRow = "date:" ~> dateTime("EEE MMM d HH:mm:ss yyyy Z")
>  private[this] def summaryRow = "summary:" ~> ".*".r
>
>
> Anyway, I just wanted to show that this would be really useful for me.
> By simply making joda-time parse CharSequences instead of Strings it
> becomes a lot easier to use as part of a stream-based
> parsing-framework.
>
> Would it be possible to make a change like this to joda-time? As I
> said, the patch linked above is just a quick and dirty fix, but I
> wanted to see that it worked. All tests pass and the only thing that
> really had to be replaced was the regionMatches()-method on String.
>
> Cheers,
> Viktor
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

Viktor Hedefalk
In reply to this post by Viktor Hedefalk
Sorry if this doesn't attach to the right thread, I didn't have any
email to reply to but saw your answer over here
http://sourceforge.net/mailarchive/message.php?msg_id=27004124.

Anyway, I really appreciate you're looking into it.

I guess the most obvious backwards compatability issue would be if
someone had implemented his own DateTimeParser. Hopefully that
shouldn't be too common though, it's really just an internal
interface, right?

Cheers,
Viktor

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

jodastephen
On 4 February 2011 23:39, Viktor Hedefalk <[hidden email]> wrote:
> I guess the most obvious backwards compatability issue would be if
> someone had implemented his own DateTimeParser. Hopefully that
> shouldn't be too common though, it's really just an internal
> interface, right?

Unfortunately, no. I have encouraged users to implement this interface
to solve some formatting issues. Thus I can't change it. Nor would I
want to create a DateTimeParser2.

Stephen

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

James Richardson-2

Well there is a major release version coming up... That would be an appropriate time to make a breaking change, no?
James

On 4 Feb 2011 23:43, "Stephen Colebourne" <[hidden email]> wrote:
> On 4 February 2011 23:39, Viktor Hedefalk <[hidden email]> wrote:
>> I guess the most obvious backwards compatability issue would be if
>> someone had implemented his own DateTimeParser. Hopefully that
>> shouldn't be too common though, it's really just an internal
>> interface, right?
>
> Unfortunately, no. I have encouraged users to implement this interface
> to solve some formatting issues. Thus I can't change it. Nor would I
> want to create a DateTimeParser2.
>
> Stephen
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

jodastephen
The problem is that the major release number is mostly about removing
a few deprecated methods. Were I to make this change it would break
user code, which no other change so far would cause. I don't want to
get into the JAR-hell situation.

Stephen


On 4 February 2011 23:57, James Richardson <[hidden email]> wrote:

> Well there is a major release version coming up... That would be an
> appropriate time to make a breaking change, no?
> James
>
> On 4 Feb 2011 23:43, "Stephen Colebourne" <[hidden email]> wrote:
>> On 4 February 2011 23:39, Viktor Hedefalk <[hidden email]> wrote:
>>> I guess the most obvious backwards compatability issue would be if
>>> someone had implemented his own DateTimeParser. Hopefully that
>>> shouldn't be too common though, it's really just an internal
>>> interface, right?
>>
>> Unfortunately, no. I have encouraged users to implement this interface
>> to solve some formatting issues. Thus I can't change it. Nor would I
>> want to create a DateTimeParser2.
>>
>> Stephen
>>
>>
>> ------------------------------------------------------------------------------
>> The modern datacenter depends on network connectivity to access resources
>> and provide services. The best practices for maximizing a physical
>> server's
>> connectivity to a physical network are well understood - see how these
>> rules translate into the virtual world?
>> http://p.sf.net/sfu/oracle-sfdevnlfb
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
>

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

James Richardson-2

I Get where you are coming from. But if you did want to make a breaking change then this would be a really appropriate place to do it. I mean if not on a major version number then when?
Just a thought.
James

On 5 Feb 2011 00:03, "Stephen Colebourne" <[hidden email]> wrote:
> The problem is that the major release number is mostly about removing
> a few deprecated methods. Were I to make this change it would break
> user code, which no other change so far would cause. I don't want to
> get into the JAR-hell situation.
>
> Stephen
>
>
> On 4 February 2011 23:57, James Richardson <[hidden email]> wrote:
>> Well there is a major release version coming up... That would be an
>> appropriate time to make a breaking change, no?
>> James
>>
>> On 4 Feb 2011 23:43, "Stephen Colebourne" <[hidden email]> wrote:
>>> On 4 February 2011 23:39, Viktor Hedefalk <[hidden email]> wrote:
>>>> I guess the most obvious backwards compatability issue would be if
>>>> someone had implemented his own DateTimeParser. Hopefully that
>>>> shouldn't be too common though, it's really just an internal
>>>> interface, right?
>>>
>>> Unfortunately, no. I have encouraged users to implement this interface
>>> to solve some formatting issues. Thus I can't change it. Nor would I
>>> want to create a DateTimeParser2.
>>>
>>> Stephen
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The modern datacenter depends on network connectivity to access resources
>>> and provide services. The best practices for maximizing a physical
>>> server's
>>> connectivity to a physical network are well understood - see how these
>>> rules translate into the virtual world?
>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>> _______________________________________________
>>> Joda-interest mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>
>>
>> ------------------------------------------------------------------------------
>> The modern datacenter depends on network connectivity to access resources
>> and provide services. The best practices for maximizing a physical server's
>> connectivity to a physical network are well understood - see how these
>> rules translate into the virtual world?
>> http://p.sf.net/sfu/oracle-sfdevnlfb
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>
>>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

jodastephen
OK.

I've looked at this, and I don't feel I can make the proposed change
without causing jar-hell. While there are no google references to
implementations, the reality is that I would be changing the main
parsing API on DateTimeFormatter, used by everyone. Methods like
parseDateTime(String).

Changing it from String to CharSequence is source compatible but
binary incompatible (method is bound at compile time).

Adding an override taking CharSequence if source compatible and binary
upwards compatible, but not downward compatible (code compiled against
the new version couldn't run on the old version.

Thus, its my opinion that the damage far outweighs the benefits on this.
Stephen


On 5 February 2011 00:11, James Richardson <[hidden email]> wrote:

> I Get where you are coming from. But if you did want to make a breaking
> change then this would be a really appropriate place to do it. I mean if not
> on a major version number then when?
> Just a thought.
> James
>
> On 5 Feb 2011 00:03, "Stephen Colebourne" <[hidden email]> wrote:
>> The problem is that the major release number is mostly about removing
>> a few deprecated methods. Were I to make this change it would break
>> user code, which no other change so far would cause. I don't want to
>> get into the JAR-hell situation.
>>
>> Stephen
>>
>>
>> On 4 February 2011 23:57, James Richardson <[hidden email]> wrote:
>>> Well there is a major release version coming up... That would be an
>>> appropriate time to make a breaking change, no?
>>> James
>>>
>>> On 4 Feb 2011 23:43, "Stephen Colebourne" <[hidden email]> wrote:
>>>> On 4 February 2011 23:39, Viktor Hedefalk <[hidden email]> wrote:
>>>>> I guess the most obvious backwards compatability issue would be if
>>>>> someone had implemented his own DateTimeParser. Hopefully that
>>>>> shouldn't be too common though, it's really just an internal
>>>>> interface, right?
>>>>
>>>> Unfortunately, no. I have encouraged users to implement this interface
>>>> to solve some formatting issues. Thus I can't change it. Nor would I
>>>> want to create a DateTimeParser2.
>>>>
>>>> Stephen
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> The modern datacenter depends on network connectivity to access
>>>> resources
>>>> and provide services. The best practices for maximizing a physical
>>>> server's
>>>> connectivity to a physical network are well understood - see how these
>>>> rules translate into the virtual world?
>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>> _______________________________________________
>>>> Joda-interest mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The modern datacenter depends on network connectivity to access resources
>>> and provide services. The best practices for maximizing a physical
>>> server's
>>> connectivity to a physical network are well understood - see how these
>>> rules translate into the virtual world?
>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>> _______________________________________________
>>> Joda-interest mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> The modern datacenter depends on network connectivity to access resources
>> and provide services. The best practices for maximizing a physical
>> server's
>> connectivity to a physical network are well understood - see how these
>> rules translate into the virtual world?
>> http://p.sf.net/sfu/oracle-sfdevnlfb
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
>

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

Viktor Hedefalk
Would it be possible to have this change in 310?

Cheers,
Viktor

On Sat, Feb 5, 2011 at 1:52 AM, Stephen Colebourne <[hidden email]> wrote:

> OK.
>
> I've looked at this, and I don't feel I can make the proposed change
> without causing jar-hell. While there are no google references to
> implementations, the reality is that I would be changing the main
> parsing API on DateTimeFormatter, used by everyone. Methods like
> parseDateTime(String).
>
> Changing it from String to CharSequence is source compatible but
> binary incompatible (method is bound at compile time).
>
> Adding an override taking CharSequence if source compatible and binary
> upwards compatible, but not downward compatible (code compiled against
> the new version couldn't run on the old version.
>
> Thus, its my opinion that the damage far outweighs the benefits on this.
> Stephen
>
>
> On 5 February 2011 00:11, James Richardson <[hidden email]> wrote:
>> I Get where you are coming from. But if you did want to make a breaking
>> change then this would be a really appropriate place to do it. I mean if not
>> on a major version number then when?
>> Just a thought.
>> James
>>
>> On 5 Feb 2011 00:03, "Stephen Colebourne" <[hidden email]> wrote:
>>> The problem is that the major release number is mostly about removing
>>> a few deprecated methods. Were I to make this change it would break
>>> user code, which no other change so far would cause. I don't want to
>>> get into the JAR-hell situation.
>>>
>>> Stephen
>>>
>>>
>>> On 4 February 2011 23:57, James Richardson <[hidden email]> wrote:
>>>> Well there is a major release version coming up... That would be an
>>>> appropriate time to make a breaking change, no?
>>>> James
>>>>
>>>> On 4 Feb 2011 23:43, "Stephen Colebourne" <[hidden email]> wrote:
>>>>> On 4 February 2011 23:39, Viktor Hedefalk <[hidden email]> wrote:
>>>>>> I guess the most obvious backwards compatability issue would be if
>>>>>> someone had implemented his own DateTimeParser. Hopefully that
>>>>>> shouldn't be too common though, it's really just an internal
>>>>>> interface, right?
>>>>>
>>>>> Unfortunately, no. I have encouraged users to implement this interface
>>>>> to solve some formatting issues. Thus I can't change it. Nor would I
>>>>> want to create a DateTimeParser2.
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> The modern datacenter depends on network connectivity to access
>>>>> resources
>>>>> and provide services. The best practices for maximizing a physical
>>>>> server's
>>>>> connectivity to a physical network are well understood - see how these
>>>>> rules translate into the virtual world?
>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>> _______________________________________________
>>>>> Joda-interest mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> The modern datacenter depends on network connectivity to access resources
>>>> and provide services. The best practices for maximizing a physical
>>>> server's
>>>> connectivity to a physical network are well understood - see how these
>>>> rules translate into the virtual world?
>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>> _______________________________________________
>>>> Joda-interest mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The modern datacenter depends on network connectivity to access resources
>>> and provide services. The best practices for maximizing a physical
>>> server's
>>> connectivity to a physical network are well understood - see how these
>>> rules translate into the virtual world?
>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>> _______________________________________________
>>> Joda-interest mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>
>>
>> ------------------------------------------------------------------------------
>> The modern datacenter depends on network connectivity to access resources
>> and provide services. The best practices for maximizing a physical server's
>> connectivity to a physical network are well understood - see how these
>> rules translate into the virtual world?
>> http://p.sf.net/sfu/oracle-sfdevnlfb
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>
>>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

jodastephen
The JSR-310 public API is based on CharSequence. The private API is
based on String.

I can't see how CharSequence alone allows you to parse a stream,
because CharSequence's methods are all about random access to a data
structure. Perhaps you can enlighten me?

Stephen


On 11 July 2011 09:32, Viktor Hedefalk <[hidden email]> wrote:

> Would it be possible to have this change in 310?
>
> Cheers,
> Viktor
>
> On Sat, Feb 5, 2011 at 1:52 AM, Stephen Colebourne <[hidden email]> wrote:
>> OK.
>>
>> I've looked at this, and I don't feel I can make the proposed change
>> without causing jar-hell. While there are no google references to
>> implementations, the reality is that I would be changing the main
>> parsing API on DateTimeFormatter, used by everyone. Methods like
>> parseDateTime(String).
>>
>> Changing it from String to CharSequence is source compatible but
>> binary incompatible (method is bound at compile time).
>>
>> Adding an override taking CharSequence if source compatible and binary
>> upwards compatible, but not downward compatible (code compiled against
>> the new version couldn't run on the old version.
>>
>> Thus, its my opinion that the damage far outweighs the benefits on this.
>> Stephen
>>
>>
>> On 5 February 2011 00:11, James Richardson <[hidden email]> wrote:
>>> I Get where you are coming from. But if you did want to make a breaking
>>> change then this would be a really appropriate place to do it. I mean if not
>>> on a major version number then when?
>>> Just a thought.
>>> James
>>>
>>> On 5 Feb 2011 00:03, "Stephen Colebourne" <[hidden email]> wrote:
>>>> The problem is that the major release number is mostly about removing
>>>> a few deprecated methods. Were I to make this change it would break
>>>> user code, which no other change so far would cause. I don't want to
>>>> get into the JAR-hell situation.
>>>>
>>>> Stephen
>>>>
>>>>
>>>> On 4 February 2011 23:57, James Richardson <[hidden email]> wrote:
>>>>> Well there is a major release version coming up... That would be an
>>>>> appropriate time to make a breaking change, no?
>>>>> James
>>>>>
>>>>> On 4 Feb 2011 23:43, "Stephen Colebourne" <[hidden email]> wrote:
>>>>>> On 4 February 2011 23:39, Viktor Hedefalk <[hidden email]> wrote:
>>>>>>> I guess the most obvious backwards compatability issue would be if
>>>>>>> someone had implemented his own DateTimeParser. Hopefully that
>>>>>>> shouldn't be too common though, it's really just an internal
>>>>>>> interface, right?
>>>>>>
>>>>>> Unfortunately, no. I have encouraged users to implement this interface
>>>>>> to solve some formatting issues. Thus I can't change it. Nor would I
>>>>>> want to create a DateTimeParser2.
>>>>>>
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> The modern datacenter depends on network connectivity to access
>>>>>> resources
>>>>>> and provide services. The best practices for maximizing a physical
>>>>>> server's
>>>>>> connectivity to a physical network are well understood - see how these
>>>>>> rules translate into the virtual world?
>>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>>> _______________________________________________
>>>>>> Joda-interest mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> The modern datacenter depends on network connectivity to access resources
>>>>> and provide services. The best practices for maximizing a physical
>>>>> server's
>>>>> connectivity to a physical network are well understood - see how these
>>>>> rules translate into the virtual world?
>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>> _______________________________________________
>>>>> Joda-interest mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> The modern datacenter depends on network connectivity to access resources
>>>> and provide services. The best practices for maximizing a physical
>>>> server's
>>>> connectivity to a physical network are well understood - see how these
>>>> rules translate into the virtual world?
>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>> _______________________________________________
>>>> Joda-interest mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The modern datacenter depends on network connectivity to access resources
>>> and provide services. The best practices for maximizing a physical server's
>>> connectivity to a physical network are well understood - see how these
>>> rules translate into the virtual world?
>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>> _______________________________________________
>>> Joda-interest mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> The modern datacenter depends on network connectivity to access resources
>> and provide services. The best practices for maximizing a physical server's
>> connectivity to a physical network are well understood - see how these
>> rules translate into the virtual world?
>> http://p.sf.net/sfu/oracle-sfdevnlfb
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

Viktor Hedefalk
I think I understand your question. I'm not really parsing a general
stream, but simply want to use JodaTime from a Scala combinator
parser. This is a complete combinator parser that simply wraps
JodaTime's DateTimeFormat (with my CharSeq-change) :

trait DateParsers extends RegexParsers {
          def dateTime(pattern: String): Parser[DateTime] = new Parser[DateTime] {
            val dateFormat = DateTimeFormat.forPattern(pattern)
            val dateParser = dateFormat.getParser
       
            def jodaParse(text: CharSequence, offset: Int) = {
              val mutableDateTime = new MutableDateTime
              val newPos = dateFormat.parseInto(mutableDateTime, text, offset);
              (mutableDateTime.toDateTime, newPos)
            }
       
            def apply(in: Input) = {
              val source = in.source
              val offset = in.offset
              val start = handleWhiteSpace(source, offset)
              val (dateTime, endPos) = jodaParse(source, start)
              if (endPos >= 0)
                Success(dateTime, in.drop(endPos - offset))
              else
                Failure("Failed to parse date", in.drop(start - offset))
            }
          }
        }


I think the relevant code to your question is the Input class defined
in the Scala standard lib:

in Parsers.scala:

 /** The parser input is an abstract reader of input elements, i.e.
the type of input the parsers in this component
   *  expect. */
  type Input = Reader[Elem]

and Reader:

/** An interface for streams of values that have positions.
 *
 * @author Martin Odersky, Adriaan Moors
 */
abstract class Reader[+T] {

  /** If this is a reader over character sequences, the underlying
char sequence
   *  If not, throws a <code>NoSuchMethodError</code> exception.
   */
  def source: java.lang.CharSequence =
    throw new NoSuchMethodError("not a char sequence reader")

  def offset: Int =
    throw new NoSuchMethodError("not a char sequence reader")

   /** Returns the first element of the reader
    */
  def first: T

  /** Returns an abstract reader consisting of all elements except the first
   *
   * @return If <code>atEnd</code> is <code>true</code>, the result will be
   *         <code>this'; otherwise, it's a <code>Reader</code> containing
   *         more elements.
   */
  def rest: Reader[T]

  /** Returns an abstract reader consisting of all elements except the first
   *  <code>n</code> elements.
   */
  def drop(n: Int): Reader[T] = {
    var r: Reader[T] = this
    var cnt = n
    while (cnt > 0) {
      r = r.rest; cnt -= 1
    }
    r
  }

  /** The position of the first element in the reader
   */
  def pos: Position

  /** true iff there are no more elements in this reader
   */
  def atEnd: Boolean
}

As you see, there is no concrete impl. of the source method that I use
to pass to JodaTime.


There are a few different implementations of Reader. One with a
noteworthy note would be:

/** A StreamReader reads from a character sequence, typically created
as a PagedSeq
 *  from a java.io.Reader
 *
 *  NOTE:
 *  StreamReaders do not really fulfill the new contract for readers, which
 *  requires a `source' CharSequence representing the full input.
 *  Instead source is treated line by line.
 *  As a consequence, regex matching cannot extend beyond a single line
 *  when a StreamReader are used for input.
 *
 *  If you need to match regexes spanning several lines you should consider
 *  class <code>PagedSeqReader</code> instead.
 *
 *  @author Miles Sabin
 *  @author Martin Odersky
 */
sealed class StreamReader(seq: PagedSeq[Char], off: Int, lnum: Int)
extends PagedSeqReader(seq, off) {


But in my case I'm doing a CLI and I actually just pass a String into
the framework. This is wrapped in a CharSequenceReader, which just
wraps a CharSequence. So I'm not really trying to parse general
streams, but rather just bridge the API-mismatch of the combinator
parsers and JodaTime. Am I making sense?


If theres a public API that's based on CharSequence that would be good
enough for me I think? If DateTimeParser or equivalent is part of the
public API? I just looked at the source over at
http://java.net/projects/jsr-310/sources/svn/content/trunk/jsr-310-ri/src/main/java/javax/time/calendar/format/DateTimeParser.java?rev=1339,
and it didn't look like it, but is this the right place to look?

Cheers,
Viktor


On Mon, Jul 11, 2011 at 10:42 AM, Stephen Colebourne
<[hidden email]> wrote:

> The JSR-310 public API is based on CharSequence. The private API is
> based on String.
>
> I can't see how CharSequence alone allows you to parse a stream,
> because CharSequence's methods are all about random access to a data
> structure. Perhaps you can enlighten me?
>
> Stephen
>
>
> On 11 July 2011 09:32, Viktor Hedefalk <[hidden email]> wrote:
>> Would it be possible to have this change in 310?
>>
>> Cheers,
>> Viktor
>>
>> On Sat, Feb 5, 2011 at 1:52 AM, Stephen Colebourne <[hidden email]> wrote:
>>> OK.
>>>
>>> I've looked at this, and I don't feel I can make the proposed change
>>> without causing jar-hell. While there are no google references to
>>> implementations, the reality is that I would be changing the main
>>> parsing API on DateTimeFormatter, used by everyone. Methods like
>>> parseDateTime(String).
>>>
>>> Changing it from String to CharSequence is source compatible but
>>> binary incompatible (method is bound at compile time).
>>>
>>> Adding an override taking CharSequence if source compatible and binary
>>> upwards compatible, but not downward compatible (code compiled against
>>> the new version couldn't run on the old version.
>>>
>>> Thus, its my opinion that the damage far outweighs the benefits on this.
>>> Stephen
>>>
>>>
>>> On 5 February 2011 00:11, James Richardson <[hidden email]> wrote:
>>>> I Get where you are coming from. But if you did want to make a breaking
>>>> change then this would be a really appropriate place to do it. I mean if not
>>>> on a major version number then when?
>>>> Just a thought.
>>>> James
>>>>
>>>> On 5 Feb 2011 00:03, "Stephen Colebourne" <[hidden email]> wrote:
>>>>> The problem is that the major release number is mostly about removing
>>>>> a few deprecated methods. Were I to make this change it would break
>>>>> user code, which no other change so far would cause. I don't want to
>>>>> get into the JAR-hell situation.
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>> On 4 February 2011 23:57, James Richardson <[hidden email]> wrote:
>>>>>> Well there is a major release version coming up... That would be an
>>>>>> appropriate time to make a breaking change, no?
>>>>>> James
>>>>>>
>>>>>> On 4 Feb 2011 23:43, "Stephen Colebourne" <[hidden email]> wrote:
>>>>>>> On 4 February 2011 23:39, Viktor Hedefalk <[hidden email]> wrote:
>>>>>>>> I guess the most obvious backwards compatability issue would be if
>>>>>>>> someone had implemented his own DateTimeParser. Hopefully that
>>>>>>>> shouldn't be too common though, it's really just an internal
>>>>>>>> interface, right?
>>>>>>>
>>>>>>> Unfortunately, no. I have encouraged users to implement this interface
>>>>>>> to solve some formatting issues. Thus I can't change it. Nor would I
>>>>>>> want to create a DateTimeParser2.
>>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> The modern datacenter depends on network connectivity to access
>>>>>>> resources
>>>>>>> and provide services. The best practices for maximizing a physical
>>>>>>> server's
>>>>>>> connectivity to a physical network are well understood - see how these
>>>>>>> rules translate into the virtual world?
>>>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>>>> _______________________________________________
>>>>>>> Joda-interest mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> The modern datacenter depends on network connectivity to access resources
>>>>>> and provide services. The best practices for maximizing a physical
>>>>>> server's
>>>>>> connectivity to a physical network are well understood - see how these
>>>>>> rules translate into the virtual world?
>>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>>> _______________________________________________
>>>>>> Joda-interest mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> The modern datacenter depends on network connectivity to access resources
>>>>> and provide services. The best practices for maximizing a physical
>>>>> server's
>>>>> connectivity to a physical network are well understood - see how these
>>>>> rules translate into the virtual world?
>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>> _______________________________________________
>>>>> Joda-interest mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> The modern datacenter depends on network connectivity to access resources
>>>> and provide services. The best practices for maximizing a physical server's
>>>> connectivity to a physical network are well understood - see how these
>>>> rules translate into the virtual world?
>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>> _______________________________________________
>>>> Joda-interest mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The modern datacenter depends on network connectivity to access resources
>>> and provide services. The best practices for maximizing a physical server's
>>> connectivity to a physical network are well understood - see how these
>>> rules translate into the virtual world?
>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>> _______________________________________________
>>> Joda-interest mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

jodastephen
ThreeTen/JSR-310 source is now at GitHub :-)

The public API is DateTimeFormatter:
https://github.com/ThreeTen/threeten/blob/master/src/main/java/javax/time/calendar/format/DateTimeFormatter.java
and that uses CharSequence

The private API for parser writers uses String as that is easier to parse with.

This seems like a fair balance, but does it work for you?

Stephen


On 11 July 2011 10:23, Viktor Hedefalk <[hidden email]> wrote:

> I think I understand your question. I'm not really parsing a general
> stream, but simply want to use JodaTime from a Scala combinator
> parser. This is a complete combinator parser that simply wraps
> JodaTime's DateTimeFormat (with my CharSeq-change) :
>
> trait DateParsers extends RegexParsers {
>          def dateTime(pattern: String): Parser[DateTime] = new Parser[DateTime] {
>            val dateFormat = DateTimeFormat.forPattern(pattern)
>            val dateParser = dateFormat.getParser
>
>            def jodaParse(text: CharSequence, offset: Int) = {
>              val mutableDateTime = new MutableDateTime
>              val newPos = dateFormat.parseInto(mutableDateTime, text, offset);
>              (mutableDateTime.toDateTime, newPos)
>            }
>
>            def apply(in: Input) = {
>              val source = in.source
>              val offset = in.offset
>              val start = handleWhiteSpace(source, offset)
>              val (dateTime, endPos) = jodaParse(source, start)
>              if (endPos >= 0)
>                Success(dateTime, in.drop(endPos - offset))
>              else
>                Failure("Failed to parse date", in.drop(start - offset))
>            }
>          }
>        }
>
>
> I think the relevant code to your question is the Input class defined
> in the Scala standard lib:
>
> in Parsers.scala:
>
>  /** The parser input is an abstract reader of input elements, i.e.
> the type of input the parsers in this component
>   *  expect. */
>  type Input = Reader[Elem]
>
> and Reader:
>
> /** An interface for streams of values that have positions.
>  *
>  * @author Martin Odersky, Adriaan Moors
>  */
> abstract class Reader[+T] {
>
>  /** If this is a reader over character sequences, the underlying
> char sequence
>   *  If not, throws a <code>NoSuchMethodError</code> exception.
>   */
>  def source: java.lang.CharSequence =
>    throw new NoSuchMethodError("not a char sequence reader")
>
>  def offset: Int =
>    throw new NoSuchMethodError("not a char sequence reader")
>
>   /** Returns the first element of the reader
>    */
>  def first: T
>
>  /** Returns an abstract reader consisting of all elements except the first
>   *
>   * @return If <code>atEnd</code> is <code>true</code>, the result will be
>   *         <code>this'; otherwise, it's a <code>Reader</code> containing
>   *         more elements.
>   */
>  def rest: Reader[T]
>
>  /** Returns an abstract reader consisting of all elements except the first
>   *  <code>n</code> elements.
>   */
>  def drop(n: Int): Reader[T] = {
>    var r: Reader[T] = this
>    var cnt = n
>    while (cnt > 0) {
>      r = r.rest; cnt -= 1
>    }
>    r
>  }
>
>  /** The position of the first element in the reader
>   */
>  def pos: Position
>
>  /** true iff there are no more elements in this reader
>   */
>  def atEnd: Boolean
> }
>
> As you see, there is no concrete impl. of the source method that I use
> to pass to JodaTime.
>
>
> There are a few different implementations of Reader. One with a
> noteworthy note would be:
>
> /** A StreamReader reads from a character sequence, typically created
> as a PagedSeq
>  *  from a java.io.Reader
>  *
>  *  NOTE:
>  *  StreamReaders do not really fulfill the new contract for readers, which
>  *  requires a `source' CharSequence representing the full input.
>  *  Instead source is treated line by line.
>  *  As a consequence, regex matching cannot extend beyond a single line
>  *  when a StreamReader are used for input.
>  *
>  *  If you need to match regexes spanning several lines you should consider
>  *  class <code>PagedSeqReader</code> instead.
>  *
>  *  @author Miles Sabin
>  *  @author Martin Odersky
>  */
> sealed class StreamReader(seq: PagedSeq[Char], off: Int, lnum: Int)
> extends PagedSeqReader(seq, off) {
> …
>
> But in my case I'm doing a CLI and I actually just pass a String into
> the framework. This is wrapped in a CharSequenceReader, which just
> wraps a CharSequence. So I'm not really trying to parse general
> streams, but rather just bridge the API-mismatch of the combinator
> parsers and JodaTime. Am I making sense?
>
>
> If theres a public API that's based on CharSequence that would be good
> enough for me I think? If DateTimeParser or equivalent is part of the
> public API? I just looked at the source over at
> http://java.net/projects/jsr-310/sources/svn/content/trunk/jsr-310-ri/src/main/java/javax/time/calendar/format/DateTimeParser.java?rev=1339,
> and it didn't look like it, but is this the right place to look?
>
> Cheers,
> Viktor
>
>
> On Mon, Jul 11, 2011 at 10:42 AM, Stephen Colebourne
> <[hidden email]> wrote:
>> The JSR-310 public API is based on CharSequence. The private API is
>> based on String.
>>
>> I can't see how CharSequence alone allows you to parse a stream,
>> because CharSequence's methods are all about random access to a data
>> structure. Perhaps you can enlighten me?
>>
>> Stephen
>>
>>
>> On 11 July 2011 09:32, Viktor Hedefalk <[hidden email]> wrote:
>>> Would it be possible to have this change in 310?
>>>
>>> Cheers,
>>> Viktor
>>>
>>> On Sat, Feb 5, 2011 at 1:52 AM, Stephen Colebourne <[hidden email]> wrote:
>>>> OK.
>>>>
>>>> I've looked at this, and I don't feel I can make the proposed change
>>>> without causing jar-hell. While there are no google references to
>>>> implementations, the reality is that I would be changing the main
>>>> parsing API on DateTimeFormatter, used by everyone. Methods like
>>>> parseDateTime(String).
>>>>
>>>> Changing it from String to CharSequence is source compatible but
>>>> binary incompatible (method is bound at compile time).
>>>>
>>>> Adding an override taking CharSequence if source compatible and binary
>>>> upwards compatible, but not downward compatible (code compiled against
>>>> the new version couldn't run on the old version.
>>>>
>>>> Thus, its my opinion that the damage far outweighs the benefits on this.
>>>> Stephen
>>>>
>>>>
>>>> On 5 February 2011 00:11, James Richardson <[hidden email]> wrote:
>>>>> I Get where you are coming from. But if you did want to make a breaking
>>>>> change then this would be a really appropriate place to do it. I mean if not
>>>>> on a major version number then when?
>>>>> Just a thought.
>>>>> James
>>>>>
>>>>> On 5 Feb 2011 00:03, "Stephen Colebourne" <[hidden email]> wrote:
>>>>>> The problem is that the major release number is mostly about removing
>>>>>> a few deprecated methods. Were I to make this change it would break
>>>>>> user code, which no other change so far would cause. I don't want to
>>>>>> get into the JAR-hell situation.
>>>>>>
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>> On 4 February 2011 23:57, James Richardson <[hidden email]> wrote:
>>>>>>> Well there is a major release version coming up... That would be an
>>>>>>> appropriate time to make a breaking change, no?
>>>>>>> James
>>>>>>>
>>>>>>> On 4 Feb 2011 23:43, "Stephen Colebourne" <[hidden email]> wrote:
>>>>>>>> On 4 February 2011 23:39, Viktor Hedefalk <[hidden email]> wrote:
>>>>>>>>> I guess the most obvious backwards compatability issue would be if
>>>>>>>>> someone had implemented his own DateTimeParser. Hopefully that
>>>>>>>>> shouldn't be too common though, it's really just an internal
>>>>>>>>> interface, right?
>>>>>>>>
>>>>>>>> Unfortunately, no. I have encouraged users to implement this interface
>>>>>>>> to solve some formatting issues. Thus I can't change it. Nor would I
>>>>>>>> want to create a DateTimeParser2.
>>>>>>>>
>>>>>>>> Stephen
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> The modern datacenter depends on network connectivity to access
>>>>>>>> resources
>>>>>>>> and provide services. The best practices for maximizing a physical
>>>>>>>> server's
>>>>>>>> connectivity to a physical network are well understood - see how these
>>>>>>>> rules translate into the virtual world?
>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>>>>> _______________________________________________
>>>>>>>> Joda-interest mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> The modern datacenter depends on network connectivity to access resources
>>>>>>> and provide services. The best practices for maximizing a physical
>>>>>>> server's
>>>>>>> connectivity to a physical network are well understood - see how these
>>>>>>> rules translate into the virtual world?
>>>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>>>> _______________________________________________
>>>>>>> Joda-interest mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> The modern datacenter depends on network connectivity to access resources
>>>>>> and provide services. The best practices for maximizing a physical
>>>>>> server's
>>>>>> connectivity to a physical network are well understood - see how these
>>>>>> rules translate into the virtual world?
>>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>>> _______________________________________________
>>>>>> Joda-interest mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> The modern datacenter depends on network connectivity to access resources
>>>>> and provide services. The best practices for maximizing a physical server's
>>>>> connectivity to a physical network are well understood - see how these
>>>>> rules translate into the virtual world?
>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>> _______________________________________________
>>>>> Joda-interest mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> The modern datacenter depends on network connectivity to access resources
>>>> and provide services. The best practices for maximizing a physical server's
>>>> connectivity to a physical network are well understood - see how these
>>>> rules translate into the virtual world?
>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>> _______________________________________________
>>>> Joda-interest mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2d-c2
>>> _______________________________________________
>>> Joda-interest mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

Viktor Hedefalk
Oh yeah, GitHub! I'll have a look…

Well, I don't know. The CharSequence I pass is the entire input which
contains stuff both before and after the date to parse. At the time
when I branched JodaTime there was a method:

DateTimeFormat.parseInto(mutableDateTime, text, offset);

that took a String and offset and returned the offset after consuming
the date. And it only used methods defined on CharSequence so the
change I made was trivial.


I guess that the method that could be possible to use in ThreeTen
would be this one?

/**
     * Parses the text into a Calendrical.
     * <p>
     * The result may be invalid including out of range values such as
a month of 65.
     * The methods on the calendrical allow you to handle the invalid input.
     * For example:
     * <pre>
     * LocalDateTime dt = parser.parse(str).mergeStrict().toLocalDateTime();
     * </pre>
     *
     * @param text  the text to parse, not null
     * @param position  the position to parse from, updated with length parsed
     *  and the index of any error, not null
     * @return the parsed text, null only if the parse results in an error
     * @throws UnsupportedOperationException if this formatter cannot parse
     * @throws IndexOutOfBoundsException if the position is invalid
     */
    public DateTimeParseContext parse(CharSequence text, ParsePosition
position) {
        DateTimeFormatter.checkNotNull(text, "Text must not be null");
        DateTimeFormatter.checkNotNull(position, "ParsePosition must
not be null");
        // parse a String as its a better API for parser writers
        String str = text.toString();
        DateTimeParseContext context = new DateTimeParseContext(symbols);
        int pos = position.getIndex();
        pos = printerParser.parse(context, str, pos);
        if (pos < 0) {
            position.setErrorIndex(~pos);
            return null;
        }
        position.setIndex(pos);
        return context;
    }


Here it returns the parsed instant inside a DateTimeParseContext and
mutates the DatePosition that was passed, am I right? This line hurts

 // parse a String as its a better API for parser writers
 String str = text.toString();

since it will be the entire input I'm parsing but I guess it probably
works in practice in my case, I'll have to try it out and get back.

Just of curiosity, what is it in String that makes it easier for parser writers?

Thanks,
Viktor









On Mon, Jul 11, 2011 at 4:48 PM, Stephen Colebourne
<[hidden email]> wrote:

> ThreeTen/JSR-310 source is now at GitHub :-)
>
> The public API is DateTimeFormatter:
> https://github.com/ThreeTen/threeten/blob/master/src/main/java/javax/time/calendar/format/DateTimeFormatter.java
> and that uses CharSequence
>
> The private API for parser writers uses String as that is easier to parse with.
>
> This seems like a fair balance, but does it work for you?
>
> Stephen
>
>
> On 11 July 2011 10:23, Viktor Hedefalk <[hidden email]> wrote:
>> I think I understand your question. I'm not really parsing a general
>> stream, but simply want to use JodaTime from a Scala combinator
>> parser. This is a complete combinator parser that simply wraps
>> JodaTime's DateTimeFormat (with my CharSeq-change) :
>>
>> trait DateParsers extends RegexParsers {
>>          def dateTime(pattern: String): Parser[DateTime] = new Parser[DateTime] {
>>            val dateFormat = DateTimeFormat.forPattern(pattern)
>>            val dateParser = dateFormat.getParser
>>
>>            def jodaParse(text: CharSequence, offset: Int) = {
>>              val mutableDateTime = new MutableDateTime
>>              val newPos = dateFormat.parseInto(mutableDateTime, text, offset);
>>              (mutableDateTime.toDateTime, newPos)
>>            }
>>
>>            def apply(in: Input) = {
>>              val source = in.source
>>              val offset = in.offset
>>              val start = handleWhiteSpace(source, offset)
>>              val (dateTime, endPos) = jodaParse(source, start)
>>              if (endPos >= 0)
>>                Success(dateTime, in.drop(endPos - offset))
>>              else
>>                Failure("Failed to parse date", in.drop(start - offset))
>>            }
>>          }
>>        }
>>
>>
>> I think the relevant code to your question is the Input class defined
>> in the Scala standard lib:
>>
>> in Parsers.scala:
>>
>>  /** The parser input is an abstract reader of input elements, i.e.
>> the type of input the parsers in this component
>>   *  expect. */
>>  type Input = Reader[Elem]
>>
>> and Reader:
>>
>> /** An interface for streams of values that have positions.
>>  *
>>  * @author Martin Odersky, Adriaan Moors
>>  */
>> abstract class Reader[+T] {
>>
>>  /** If this is a reader over character sequences, the underlying
>> char sequence
>>   *  If not, throws a <code>NoSuchMethodError</code> exception.
>>   */
>>  def source: java.lang.CharSequence =
>>    throw new NoSuchMethodError("not a char sequence reader")
>>
>>  def offset: Int =
>>    throw new NoSuchMethodError("not a char sequence reader")
>>
>>   /** Returns the first element of the reader
>>    */
>>  def first: T
>>
>>  /** Returns an abstract reader consisting of all elements except the first
>>   *
>>   * @return If <code>atEnd</code> is <code>true</code>, the result will be
>>   *         <code>this'; otherwise, it's a <code>Reader</code> containing
>>   *         more elements.
>>   */
>>  def rest: Reader[T]
>>
>>  /** Returns an abstract reader consisting of all elements except the first
>>   *  <code>n</code> elements.
>>   */
>>  def drop(n: Int): Reader[T] = {
>>    var r: Reader[T] = this
>>    var cnt = n
>>    while (cnt > 0) {
>>      r = r.rest; cnt -= 1
>>    }
>>    r
>>  }
>>
>>  /** The position of the first element in the reader
>>   */
>>  def pos: Position
>>
>>  /** true iff there are no more elements in this reader
>>   */
>>  def atEnd: Boolean
>> }
>>
>> As you see, there is no concrete impl. of the source method that I use
>> to pass to JodaTime.
>>
>>
>> There are a few different implementations of Reader. One with a
>> noteworthy note would be:
>>
>> /** A StreamReader reads from a character sequence, typically created
>> as a PagedSeq
>>  *  from a java.io.Reader
>>  *
>>  *  NOTE:
>>  *  StreamReaders do not really fulfill the new contract for readers, which
>>  *  requires a `source' CharSequence representing the full input.
>>  *  Instead source is treated line by line.
>>  *  As a consequence, regex matching cannot extend beyond a single line
>>  *  when a StreamReader are used for input.
>>  *
>>  *  If you need to match regexes spanning several lines you should consider
>>  *  class <code>PagedSeqReader</code> instead.
>>  *
>>  *  @author Miles Sabin
>>  *  @author Martin Odersky
>>  */
>> sealed class StreamReader(seq: PagedSeq[Char], off: Int, lnum: Int)
>> extends PagedSeqReader(seq, off) {
>> …
>>
>> But in my case I'm doing a CLI and I actually just pass a String into
>> the framework. This is wrapped in a CharSequenceReader, which just
>> wraps a CharSequence. So I'm not really trying to parse general
>> streams, but rather just bridge the API-mismatch of the combinator
>> parsers and JodaTime. Am I making sense?
>>
>>
>> If theres a public API that's based on CharSequence that would be good
>> enough for me I think? If DateTimeParser or equivalent is part of the
>> public API? I just looked at the source over at
>> http://java.net/projects/jsr-310/sources/svn/content/trunk/jsr-310-ri/src/main/java/javax/time/calendar/format/DateTimeParser.java?rev=1339,
>> and it didn't look like it, but is this the right place to look?
>>
>> Cheers,
>> Viktor
>>
>>
>> On Mon, Jul 11, 2011 at 10:42 AM, Stephen Colebourne
>> <[hidden email]> wrote:
>>> The JSR-310 public API is based on CharSequence. The private API is
>>> based on String.
>>>
>>> I can't see how CharSequence alone allows you to parse a stream,
>>> because CharSequence's methods are all about random access to a data
>>> structure. Perhaps you can enlighten me?
>>>
>>> Stephen
>>>
>>>
>>> On 11 July 2011 09:32, Viktor Hedefalk <[hidden email]> wrote:
>>>> Would it be possible to have this change in 310?
>>>>
>>>> Cheers,
>>>> Viktor
>>>>
>>>> On Sat, Feb 5, 2011 at 1:52 AM, Stephen Colebourne <[hidden email]> wrote:
>>>>> OK.
>>>>>
>>>>> I've looked at this, and I don't feel I can make the proposed change
>>>>> without causing jar-hell. While there are no google references to
>>>>> implementations, the reality is that I would be changing the main
>>>>> parsing API on DateTimeFormatter, used by everyone. Methods like
>>>>> parseDateTime(String).
>>>>>
>>>>> Changing it from String to CharSequence is source compatible but
>>>>> binary incompatible (method is bound at compile time).
>>>>>
>>>>> Adding an override taking CharSequence if source compatible and binary
>>>>> upwards compatible, but not downward compatible (code compiled against
>>>>> the new version couldn't run on the old version.
>>>>>
>>>>> Thus, its my opinion that the damage far outweighs the benefits on this.
>>>>> Stephen
>>>>>
>>>>>
>>>>> On 5 February 2011 00:11, James Richardson <[hidden email]> wrote:
>>>>>> I Get where you are coming from. But if you did want to make a breaking
>>>>>> change then this would be a really appropriate place to do it. I mean if not
>>>>>> on a major version number then when?
>>>>>> Just a thought.
>>>>>> James
>>>>>>
>>>>>> On 5 Feb 2011 00:03, "Stephen Colebourne" <[hidden email]> wrote:
>>>>>>> The problem is that the major release number is mostly about removing
>>>>>>> a few deprecated methods. Were I to make this change it would break
>>>>>>> user code, which no other change so far would cause. I don't want to
>>>>>>> get into the JAR-hell situation.
>>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>>
>>>>>>> On 4 February 2011 23:57, James Richardson <[hidden email]> wrote:
>>>>>>>> Well there is a major release version coming up... That would be an
>>>>>>>> appropriate time to make a breaking change, no?
>>>>>>>> James
>>>>>>>>
>>>>>>>> On 4 Feb 2011 23:43, "Stephen Colebourne" <[hidden email]> wrote:
>>>>>>>>> On 4 February 2011 23:39, Viktor Hedefalk <[hidden email]> wrote:
>>>>>>>>>> I guess the most obvious backwards compatability issue would be if
>>>>>>>>>> someone had implemented his own DateTimeParser. Hopefully that
>>>>>>>>>> shouldn't be too common though, it's really just an internal
>>>>>>>>>> interface, right?
>>>>>>>>>
>>>>>>>>> Unfortunately, no. I have encouraged users to implement this interface
>>>>>>>>> to solve some formatting issues. Thus I can't change it. Nor would I
>>>>>>>>> want to create a DateTimeParser2.
>>>>>>>>>
>>>>>>>>> Stephen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> The modern datacenter depends on network connectivity to access
>>>>>>>>> resources
>>>>>>>>> and provide services. The best practices for maximizing a physical
>>>>>>>>> server's
>>>>>>>>> connectivity to a physical network are well understood - see how these
>>>>>>>>> rules translate into the virtual world?
>>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>>>>>> _______________________________________________
>>>>>>>>> Joda-interest mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> The modern datacenter depends on network connectivity to access resources
>>>>>>>> and provide services. The best practices for maximizing a physical
>>>>>>>> server's
>>>>>>>> connectivity to a physical network are well understood - see how these
>>>>>>>> rules translate into the virtual world?
>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>>>>> _______________________________________________
>>>>>>>> Joda-interest mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> The modern datacenter depends on network connectivity to access resources
>>>>>>> and provide services. The best practices for maximizing a physical
>>>>>>> server's
>>>>>>> connectivity to a physical network are well understood - see how these
>>>>>>> rules translate into the virtual world?
>>>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>>>> _______________________________________________
>>>>>>> Joda-interest mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> The modern datacenter depends on network connectivity to access resources
>>>>>> and provide services. The best practices for maximizing a physical server's
>>>>>> connectivity to a physical network are well understood - see how these
>>>>>> rules translate into the virtual world?
>>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>>> _______________________________________________
>>>>>> Joda-interest mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> The modern datacenter depends on network connectivity to access resources
>>>>> and provide services. The best practices for maximizing a physical server's
>>>>> connectivity to a physical network are well understood - see how these
>>>>> rules translate into the virtual world?
>>>>> http://p.sf.net/sfu/oracle-sfdevnlfb
>>>>> _______________________________________________
>>>>> Joda-interest mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All of the data generated in your IT infrastructure is seriously valuable.
>>>> Why? It contains a definitive record of application performance, security
>>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>>> sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-d2d-c2
>>>> _______________________________________________
>>>> Joda-interest mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2d-c2
>>> _______________________________________________
>>> Joda-interest mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

jodastephen
On 11 July 2011 19:21, Viktor Hedefalk <[hidden email]> wrote:
> I guess that the method that could be possible to use in ThreeTen
> would be this one?
>    public DateTimeParseContext parse(CharSequence text, ParsePosition
> position) {

If you need the ParsePosition, then that is the one.

> This line hurts
>
>  // parse a String as its a better API for parser writers
>  String str = text.toString();
>
> since it will be the entire input I'm parsing but I guess it probably
> works in practice in my case, I'll have to try it out and get back.

Thats the current choice I'm making, CharSequence outside, String inside.

> Just of curiosity, what is it in String that makes it easier for parser writers?

Its just a bigger API, with startsWith, contains, indexOf,
regionMatches ... I tried to convert it to CharSeq internally, but it
seemed like more hassle than it was worth. If you can convince me its
really a major hassle or performance issue, then I might accept a pull
request, but I'd prefer not to if possible.

Stephen

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

Viktor Hedefalk
Ok, thanks!

I could change my parser combinator to look like this:

trait DateParsers extends RegexParsers {
  def dateTime(pattern: String) = new Parser[LocalDate] {
    val dateFormat = DateTimeFormatters.pattern(pattern)

    def jodaParse(text: CharSequence, offset: Int) = {
      val parsePosition = new ParsePosition(offset)
      val result = dateFormat.parse(text, parsePosition)
      val date = () => result.toCalendricalMerger().getDate(false)
      (date, parsePosition)
    }

    def apply(in: Input) = {
      val source = in.source
      val offset = in.offset
      val start = handleWhiteSpace(source, offset)
      val (date, parsePosition) = jodaParse(source, start)
      if (parsePosition.getErrorIndex >= 0)
     Failure("Failed to parse date", in.drop(start - offset))
      else
     Success(date(), in.drop(parsePosition.getIndex - offset))
    }
  }
}

to get a LocalDate. I'll look into ThreeTen a bit more to see what
I'll use exactly, but anyways it seems to work - my enormous bulk of
tests from that old project passes :) :


class DateParserSpec extends FlatSpec with ShouldMatchers with DateParsers {
  "A DateParser" should "fail on weird output" in {
    val result = parseAll(dateTime("EEE MMM d HH:mm:ss"), "   xxx")
    result.successful should be(false)
  }
  it should "run fine on a matching date" in {
    val result = parseAll(dateTime("EEE MMM d HH:mm:ss yyyy Z"), "Wed
Aug 12 18:49:56 2009 +0200")
    result.successful should be(true)
  }
  it should "run fine on another matching date" in {
        val result = parseAll(dateTime("HH:ss:mm yyyy MMM"), "  22:56:23 2010 Jan  ")
        result.successful should be (true)
  }
}


 I still really think that the call to toString() is a problem. Sure a
CharSequence is a random access datastructure but it is still very
usable from a streaming point of view as long as you don't look ahead
to much. This is exactly how the scala combinator parsers work. Look
at for instance PagedSeq:

http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/scala/collection/immutable/PagedSeq$.html

This is a lazily evaluated sequence a that stores the elements in
pages of fixed length arrays. And I can do:

val input = PagedSeqReader(PagedSeq.fromFile(new
File("my/path/file.txt")) and use this lazy character stream straight
away in my combinator parser.

The toString method turns it to eager:

/** Convert sequence to string */
  override def toString = {
    val buf = new StringBuilder
    for (ch <- PagedSeq.this.iterator) buf append ch
    buf.toString
  }

which would make my date parsing-wrapper unusable from say a stream
over a network or a really large file.

I've looked at it again and to me it doesn't seem too hard to fix:
https://github.com/hedefalk/threeten/commit/517c1bcc6d7c4982f90a41781506d2616e9772f4
- tests pass.

But then again I might be biased since I think this one is very important ;)

The biggest issue is regionMatches i guess and I had to introduce a
Util-class again. If I were to issue a pull request, what would be
your preferred way of handling that one?

Thanks,
Viktor


On Mon, Jul 11, 2011 at 8:53 PM, Stephen Colebourne
<[hidden email]> wrote:

> On 11 July 2011 19:21, Viktor Hedefalk <[hidden email]> wrote:
>> I guess that the method that could be possible to use in ThreeTen
>> would be this one?
>>    public DateTimeParseContext parse(CharSequence text, ParsePosition
>> position) {
>
> If you need the ParsePosition, then that is the one.
>
>> This line hurts
>>
>>  // parse a String as its a better API for parser writers
>>  String str = text.toString();
>>
>> since it will be the entire input I'm parsing but I guess it probably
>> works in practice in my case, I'll have to try it out and get back.
>
> Thats the current choice I'm making, CharSequence outside, String inside.
>
>> Just of curiosity, what is it in String that makes it easier for parser writers?
>
> Its just a bigger API, with startsWith, contains, indexOf,
> regionMatches ... I tried to convert it to CharSeq internally, but it
> seemed like more hassle than it was worth. If you can convince me its
> really a major hassle or performance issue, then I might accept a pull
> request, but I'd prefer not to if possible.
>
> Stephen
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: CharSequence instead of Strings for parsing…

jodastephen
On 11 July 2011 21:46, Viktor Hedefalk <[hidden email]> wrote:
> I've looked at it again and to me it doesn't seem too hard to fix:
> https://github.com/hedefalk/threeten/commit/517c1bcc6d7c4982f90a41781506d2616e9772f4
> - tests pass.
>
> But then again I might be biased since I think this one is very important ;)
>
> The biggest issue is regionMatches i guess and I had to introduce a
> Util-class again. If I were to issue a pull request, what would be
> your preferred way of handling that one?

You have to agree to the contribution agreement. A comment on the pull
request or a mail to the threeten-devel list.
https://github.com/ThreeTen/threeten/blob/master/COPYRIGHT-ASSIGN.txt
https://github.com/ThreeTen/threeten/pull/1

Stephen

------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Loading...