Re: [Factor-talk] Formatting Durations
Hello, John! 20.07.2016, 18:34, "John Benediktsson" :If all you want is to normalize to days, then something like this would work: : normalize-to-days ( duration -- duration ) [ 60 /mod ] change-second [ + 60 /mod ] change-minute [ + 24 /mod ] change-hour [ + ] change-day ; Perfect! Could you add this to the calendar vocab, please? ---=---Александр -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Formatting Durations
If all you want is to normalize to days, then something like this would work: : normalize-to-days ( duration -- duration ) [ 60 /mod ] change-second [ + 60 /mod ] change-minute [ + 24 /mod ] change-hour [ + ] change-day ; On Wed, Jul 20, 2016 at 8:18 AM, Alexander Ilin wrote: > Hello! > > 20.07.2016, 17:59, "John Benediktsson" : > > I think the reason there is no "normalize" is because duration can have > months and years and those mean different things depending on what > timestamp they are relative to. > > > > I don't quite understand. Are you talking about the different number of > seconds in different years? If that's the case, then we are indeed screwed. > > I'm proposing to only normalize the part of duration that deals with > seconds, minutes, hours and days. Maybe with a warning about leap years and > such in the documentation. If we agree that days are always 24*60*60 > seconds long, then we can put all the overflow into days and be done with > it. That's all the normalization I need. Everything above days would be > subjected to days-in-month and other limitations, which are only usefully > known when applied to the specific timestamps with time+ and time-. > > Maybe if days can have different lengths (I'm not an expert in this), > then can we at least state that hours are 60*60 seconds long? > > Maybe normalize-time would be a better name. > > > Agreed on localization, someone we also need for number printing. It just > hasn't been built yet. > > > Oh, I'm so glad that's not in yet, because I prefer to have consistent > formatting to one that's always localized. One of the pitfalls I happened > to step into (and some of my fellow developers discussed same issue but a > few months ago) is storing numbers in a text file, and then failing to load > them properly due to comma vs. dot as the decimal separator on source vs. > target PCs. That presentation-level stuff needs to be purposely activated > on the outer layers of the system, not automatically enforced in the core. > That's my opinion. > > ---=--- > Александр > > > > -- > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports.http://sdm.link/zohodev2dev > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > > -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Formatting Durations
Hello! 20.07.2016, 17:59, "John Benediktsson" :I think the reason there is no "normalize" is because duration can have months and years and those mean different things depending on what timestamp they are relative to. I don't quite understand. Are you talking about the different number of seconds in different years? If that's the case, then we are indeed screwed. I'm proposing to only normalize the part of duration that deals with seconds, minutes, hours and days. Maybe with a warning about leap years and such in the documentation. If we agree that days are always 24*60*60 seconds long, then we can put all the overflow into days and be done with it. That's all the normalization I need. Everything above days would be subjected to days-in-month and other limitations, which are only usefully known when applied to the specific timestamps with time+ and time-. Maybe if days can have different lengths (I'm not an expert in this), then can we at least state that hours are 60*60 seconds long? Maybe normalize-time would be a better name. Agreed on localization, someone we also need for number printing. It just hasn't been built yet. Oh, I'm so glad that's not in yet, because I prefer to have consistent formatting to one that's always localized. One of the pitfalls I happened to step into (and some of my fellow developers discussed same issue but a few months ago) is storing numbers in a text file, and then failing to load them properly due to comma vs. dot as the decimal separator on source vs. target PCs. That presentation-level stuff needs to be purposely activated on the outer layers of the system, not automatically enforced in the core. That's my opinion. ---=---Александр -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Formatting Durations
I think the reason there is no "normalize" is because duration can have
months and years and those mean different things depending on what
timestamp they are relative to.
Agreed on localization, someone we also need for number printing. It just
hasn't been built yet.
On Wed, Jul 20, 2016 at 7:53 AM, Alexander Ilin wrote:
> Hello, John and Jon!
>
> You both are very helpful, thank you for your replies.
>
> Continuing this general discussion of the calendar* vocabs, I wanted to
> note that I didn't notice anything like a "normalize" word for durations or
> timestamps. That would be very useful for my case. I'd like to have
> something like this:
>
> 3600 seconds normalize
> T{ duration f 0 0 0 0 1 0 0 }
> instead of
> T{ duration f 0 0 0 0 0 0 3600 }
>
> I.e. it should make sure all the lower slots with known limits hold
> valid values (0..60 for seconds and minutes, 0..24 for hours, any number
> for days).
> The question is, however, whether we should allow an arbitrary number of
> days or hours. I guess days are better, and if someone needs to report 26
> hours instead of 1 day 2 hours, it's easy to multiply by 24 and add.
>
> It's a matter of formatting, you see. If I call duration>hms, I want to
> see 26:00:00 rather than 02:00:00 or "1 day 02:00:00".
>
> And lastly, I see that we format times with the colon character. Is
> there a way to make sure the formatting is driven by the current system
> locale settings?
> I agree that the lowest level functions should produce the same string
> on any system for portability (i.e. use ":" for time separation), but if we
> want to present data to users, it might be a good idea to replace ":" with
> something locale-specific, don't you agree? For example, this link seems to
> suggest that in Italy they use the dot (".") as the time separator:
> https://msdn.microsoft.com/en-us/library/8kb3ddd4(v=vs.110).aspx
>
> 20.07.2016, 17:03, "John Benediktsson" :
>
> I would be surprised if that word becomes a bottleneck, but I can
> understand trying to be performance-aware as you build out a system.
>
> Are you dealing with floating point numbers of seconds? Because if so, I
> would guess it easier/faster/more correct to round the number of seconds
> first and then operate on integers. If you aren't dealing with floats,
> then rounding is redundant. So, perhaps something like this:
>
> : seconds>hms ( n -- str )
> round >integer 60 /mod [ 60 /mod ] dip 3array [ pad-00 ] map ":"
> join ;
>
>
> For what it's worth, using formatting is only like 5-7% slower:
>
> "%02d:%02d:%02d" sprintf
>
> Than this equivalent set of sequence operations:
>
> 3array [ pad-00 ] map ":" join
>
>
>
> That's a good idea, I keep forgetting about that formatting option. If
> it's shorter than the original, I'll use that, because performance is not
> an issue per se in my use case (it's UI, not number crunching).
>
>
> On Wed, Jul 20, 2016 at 6:19 AM, Jon Harper
> wrote:
>
> Regarding over engineering, I think that the composability of factor's
> libraries make the object allocations worth it. See
> https://docs.factorcode.org/content/article-cookbook-philosophy.html "Object
> allocation is very cheap. Don't be afraid to create tuples [...]".
>
> However, the restriction to timestamps with TYPED: was added exactly (see
> b059ade5eda) to prevent using those words on durations. That's because
> their internal state doesn't behave like timestamps and you must call the
> duration>XX words instead of accessing the slots directly:
>
> 3600 seconds (timestamp>hms)
> 00:00:3600
>
> 3600 seconds duration>hm
> "01:00"
>
> It looks like we could have more duration>XXX formatting words ?
>
>
> Yes, I need duration>hms. When I tested with (timestamp>hms), I did
> prepare the hours-minutes-seconds split myself before calling the word, so
> the type restriction was not needed in my specific case, but I get your
> point.
>
>
> Also, in calendar.format, write-gmt-offset and write-rfc3339-gmt-offset
> access the slots directly. So now we have:
> 2010 10 10 10 10 10 1 hours timestamp>rfc822
> "Sun, 10 Oct 2010 10:10:10 +0100"
> 2010 10 10 10 10 10 3600 seconds timestamp>rfc822 .
> "Sun, 10 Oct 2010 10:10:10 +"
>
> Bug of feature ? :)
>
>
>
> Ha! Nice question. : ) I guess a "normalize" I suggested above could
> help here if used within timestamp>rfc822.
>
> ---=---
> Александр
>
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net
Re: [Factor-talk] Formatting Durations
Hello, John and Jon! You both are very helpful, thank you for your replies. Continuing this general discussion of the calendar* vocabs, I wanted to note that I didn't notice anything like a "normalize" word for durations or timestamps. That would be very useful for my case. I'd like to have something like this: 3600 seconds normalizeT{ duration f 0 0 0 0 1 0 0 } instead ofT{ duration f 0 0 0 0 0 0 3600 } I.e. it should make sure all the lower slots with known limits hold valid values (0..60 for seconds and minutes, 0..24 for hours, any number for days). The question is, however, whether we should allow an arbitrary number of days or hours. I guess days are better, and if someone needs to report 26 hours instead of 1 day 2 hours, it's easy to multiply by 24 and add. It's a matter of formatting, you see. If I call duration>hms, I want to see 26:00:00 rather than 02:00:00 or "1 day 02:00:00". And lastly, I see that we format times with the colon character. Is there a way to make sure the formatting is driven by the current system locale settings? I agree that the lowest level functions should produce the same string on any system for portability (i.e. use ":" for time separation), but if we want to present data to users, it might be a good idea to replace ":" with something locale-specific, don't you agree? For example, this link seems to suggest that in Italy they use the dot (".") as the time separator: https://msdn.microsoft.com/en-us/library/8kb3ddd4(v=vs.110).aspx 20.07.2016, 17:03, "John Benediktsson" :I would be surprised if that word becomes a bottleneck, but I can understand trying to be performance-aware as you build out a system. Are you dealing with floating point numbers of seconds? Because if so, I would guess it easier/faster/more correct to round the number of seconds first and then operate on integers. If you aren't dealing with floats, then rounding is redundant. So, perhaps something like this: : seconds>hms ( n -- str ) round >integer 60 /mod [ 60 /mod ] dip 3array [ pad-00 ] map ":" join ; For what it's worth, using formatting is only like 5-7% slower: "%02d:%02d:%02d" sprintf Than this equivalent set of sequence operations: 3array [ pad-00 ] map ":" join That's a good idea, I keep forgetting about that formatting option. If it's shorter than the original, I'll use that, because performance is not an issue per se in my use case (it's UI, not number crunching). On Wed, Jul 20, 2016 at 6:19 AM, Jon Harper wrote:Regarding over engineering, I think that the composability of factor's libraries make the object allocations worth it. See https://docs.factorcode.org/content/article-cookbook-philosophy.html "Object allocation is very cheap. Don't be afraid to create tuples [...]". However, the restriction to timestamps with TYPED: was added exactly (see b059ade5eda) to prevent using those words on durations. That's because their internal state doesn't behave like timestamps and you must call the duration>XX words instead of accessing the slots directly:3600 seconds (timestamp>hms)00:00:36003600 seconds duration>hm"01:00"It looks like we could have more duration>XXX formatting words ? Yes, I need duration>hms. When I tested with (timestamp>hms), I did prepare the hours-minutes-seconds split myself before calling the word, so the type restriction was not needed in my specific case, but I get your point. Also, in calendar.format, write-gmt-offset and write-rfc3339-gmt-offset access the slots directly. So now we have:2010 10 10 10 10 10 1 hours timestamp>rfc822"Sun, 10 Oct 2010 10:10:10 +0100"2010 10 10 10 10 10 3600 seconds timestamp>rfc822 ."Sun, 10 Oct 2010 10:10:10 +" Bug of feature ? :) Ha! Nice question. : ) I guess a "normalize" I suggested above could help here if used within timestamp>rfc822. ---=---Александр --
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Formatting Durations
I would be surprised if that word becomes a bottleneck, but I can understand trying to be performance-aware as you build out a system. Are you dealing with floating point numbers of seconds? Because if so, I would guess it easier/faster/more correct to round the number of seconds first and then operate on integers. If you aren't dealing with floats, then rounding is redundant. So, perhaps something like this: : seconds>hms ( n -- str ) round >integer 60 /mod [ 60 /mod ] dip 3array [ pad-00 ] map ":" join ; For what it's worth, using formatting is only like 5-7% slower: "%02d:%02d:%02d" sprintf Than this equivalent set of sequence operations: 3array [ pad-00 ] map ":" join Best, John. On Wed, Jul 20, 2016 at 6:19 AM, Jon Harper wrote: > Regarding over engineering, I think that the composability of factor's > libraries make the object allocations worth it. See > https://docs.factorcode.org/content/article-cookbook-philosophy.html "Object > allocation is very cheap. Don't be afraid to create tuples [...]". > > However, the restriction to timestamps with TYPED: was added exactly (see > b059ade5eda) to prevent using those words on durations. That's because > their internal state doesn't behave like timestamps and you must call the > duration>XX words instead of accessing the slots directly: > > 3600 seconds (timestamp>hms) > 00:00:3600 > > 3600 seconds duration>hm > "01:00" > > It looks like we could have more duration>XXX formatting words ? > > Also, in calendar.format, write-gmt-offset and write-rfc3339-gmt-offset > access the slots directly. So now we have: > 2010 10 10 10 10 10 1 hours timestamp>rfc822 > "Sun, 10 Oct 2010 10:10:10 +0100" > 2010 10 10 10 10 10 3600 seconds timestamp>rfc822 . > "Sun, 10 Oct 2010 10:10:10 +" > > Bug of feature ? :) > > > > Jon > > On Wed, Jul 20, 2016 at 10:07 AM, Alexander Ilin wrote: > >> Hello! >> >> On the second thought, that may be overengineering a bit. After all, do >> I need to create a duration object and a string stream (within a namespace >> to override output-stream) just to do some string manipulation? Here's a >> solution with smaller overhead : >> >> : seconds>hms ( n -- str ) >> 60 /mod round [ 60 /mod round ] dip 3array [ pad-00 ] map ":" join ; >> >> 20.07.2016, 10:44, "Alexander Ilin" : >> > Hello! >> > >> > I'm measuring some processes, which take anywhere from seconds to >> hours to run. >> > I record the number of seconds in a DB for future reference. >> > When presenting the data to the user (myself) I want to see a >> hh:mm:ss string instead of thousands of seconds. >> > >> > Is there a way to format a duration tuple in such a way? The closest >> thing I found is timestamp>hms, which does exactly what I want, but it is >> TYPED:, and only accepts timestamps. Can I add the following word to the >> calendar.format, or is there a better way? >> > >> > TYPED: duration>hms ( duration: duration -- str ) >> > [ (timestamp>hms) ] with-string-writer ; >> > >> > ---=--- >> > Александр >> > >> > >> -- >> > What NetFlow Analyzer can do for you? Monitors network bandwidth and >> traffic >> > patterns at an interface-level. Reveals which users, apps, and >> protocols are >> > consuming the most bandwidth. Provides multi-vendor support for NetFlow, >> > J-Flow, sFlow and other flows. Make informed decisions using capacity >> planning >> > reports.http://sdm.link/zohodev2dev >> > ___ >> > Factor-talk mailing list >> > Factor-talk@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/factor-talk >> >> ---=--- >> Александр >> >> >> -- >> What NetFlow Analyzer can do for you? Monitors network bandwidth and >> traffic >> patterns at an interface-level. Reveals which users, apps, and protocols >> are >> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >> J-Flow, sFlow and other flows. Make informed decisions using capacity >> planning >> reports.http://sdm.link/zohodev2dev >> ___ >> Factor-talk mailing list >> Factor-talk@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/factor-talk >> > > > > -- > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports.http://sdm.link/zohodev2dev > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > > --
Re: [Factor-talk] Formatting Durations
Regarding over engineering, I think that the composability of factor's libraries make the object allocations worth it. See https://docs.factorcode.org/content/article-cookbook-philosophy.html "Object allocation is very cheap. Don't be afraid to create tuples [...]". However, the restriction to timestamps with TYPED: was added exactly (see b059ade5eda) to prevent using those words on durations. That's because their internal state doesn't behave like timestamps and you must call the duration>XX words instead of accessing the slots directly: 3600 seconds (timestamp>hms) 00:00:3600 3600 seconds duration>hm "01:00" It looks like we could have more duration>XXX formatting words ? Also, in calendar.format, write-gmt-offset and write-rfc3339-gmt-offset access the slots directly. So now we have: 2010 10 10 10 10 10 1 hours timestamp>rfc822 "Sun, 10 Oct 2010 10:10:10 +0100" 2010 10 10 10 10 10 3600 seconds timestamp>rfc822 . "Sun, 10 Oct 2010 10:10:10 +" Bug of feature ? :) Jon On Wed, Jul 20, 2016 at 10:07 AM, Alexander Ilin wrote: > Hello! > > On the second thought, that may be overengineering a bit. After all, do > I need to create a duration object and a string stream (within a namespace > to override output-stream) just to do some string manipulation? Here's a > solution with smaller overhead : > > : seconds>hms ( n -- str ) > 60 /mod round [ 60 /mod round ] dip 3array [ pad-00 ] map ":" join ; > > 20.07.2016, 10:44, "Alexander Ilin" : > > Hello! > > > > I'm measuring some processes, which take anywhere from seconds to > hours to run. > > I record the number of seconds in a DB for future reference. > > When presenting the data to the user (myself) I want to see a hh:mm:ss > string instead of thousands of seconds. > > > > Is there a way to format a duration tuple in such a way? The closest > thing I found is timestamp>hms, which does exactly what I want, but it is > TYPED:, and only accepts timestamps. Can I add the following word to the > calendar.format, or is there a better way? > > > > TYPED: duration>hms ( duration: duration -- str ) > > [ (timestamp>hms) ] with-string-writer ; > > > > ---=--- > > Александр > > > > > -- > > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > > patterns at an interface-level. Reveals which users, apps, and protocols > are > > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > > reports.http://sdm.link/zohodev2dev > > ___ > > Factor-talk mailing list > > Factor-talk@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/factor-talk > > ---=--- > Александр > > > -- > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports.http://sdm.link/zohodev2dev > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Formatting Durations
Hello! On the second thought, that may be overengineering a bit. After all, do I need to create a duration object and a string stream (within a namespace to override output-stream) just to do some string manipulation? Here's a solution with smaller overhead : : seconds>hms ( n -- str ) 60 /mod round [ 60 /mod round ] dip 3array [ pad-00 ] map ":" join ; 20.07.2016, 10:44, "Alexander Ilin" : > Hello! > > I'm measuring some processes, which take anywhere from seconds to hours to > run. > I record the number of seconds in a DB for future reference. > When presenting the data to the user (myself) I want to see a hh:mm:ss > string instead of thousands of seconds. > > Is there a way to format a duration tuple in such a way? The closest thing > I found is timestamp>hms, which does exactly what I want, but it is TYPED:, > and only accepts timestamps. Can I add the following word to the > calendar.format, or is there a better way? > > TYPED: duration>hms ( duration: duration -- str ) > [ (timestamp>hms) ] with-string-writer ; > > ---=--- > Александр > > -- > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity planning > reports.http://sdm.link/zohodev2dev > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk ---=--- Александр -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] Formatting Durations
Hello! I'm measuring some processes, which take anywhere from seconds to hours to run. I record the number of seconds in a DB for future reference. When presenting the data to the user (myself) I want to see a hh:mm:ss string instead of thousands of seconds. Is there a way to format a duration tuple in such a way? The closest thing I found is timestamp>hms, which does exactly what I want, but it is TYPED:, and only accepts timestamps. Can I add the following word to the calendar.format, or is there a better way? TYPED: duration>hms ( duration: duration -- str ) [ (timestamp>hms) ] with-string-writer ; ---=--- Александр -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
