Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #16110 > unrolled thread
| Started by | "R.Wieser" <address@not.available> |
|---|---|
| First post | 2016-01-06 17:18 +0100 |
| Last post | 2016-01-12 16:11 +0100 |
| Articles | 20 on this page of 114 — 10 participants |
Back to article view | Back to comp.lang.php
parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-06 17:18 +0100
Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-06 19:28 +0000
Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-06 20:50 +0100
Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-06 21:12 +0000
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-06 16:20 -0500
Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 02:23 +0000
Re: parsing print_r() output with preg_match_all() Matthew Carter <m@ahungry.com> - 2016-01-06 21:48 -0500
Re: parsing print_r() output with preg_match_all() Matthew Carter <m@ahungry.com> - 2016-01-06 21:52 -0500
Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 10:20 +0100
Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 10:56 +0000
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 12:55 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-07 08:36 -0500
Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 13:58 +0000
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 15:33 +0100
Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 15:31 +0000
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 18:23 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-06 22:50 -0500
Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 10:10 +0100
Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 10:03 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-07 08:38 -0500
Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 14:05 +0000
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-07 13:42 -0500
Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 20:24 +0000
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-07 15:27 -0500
Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 09:51 +0100
Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 11:18 +0000
Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 14:00 +0100
Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 14:00 +0000
Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 16:19 +0100
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 09:11 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 08:04 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 23:48 +0100
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-12 00:41 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 20:53 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 05:40 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 09:12 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 21:43 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 16:12 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 22:28 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 16:35 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-13 06:39 +0100
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-13 08:26 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 08:10 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-13 14:49 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 10:08 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-13 18:50 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 15:06 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-13 23:11 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 17:18 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-13 23:27 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 19:17 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 01:30 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 20:52 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 08:13 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-14 09:18 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 20:07 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-14 16:06 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 22:41 +0100
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-14 22:35 +0100
Re: parsing print_r() output with preg_match_all() Ian Collins <ian-news@hotmail.com> - 2016-01-14 10:24 +1300
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 17:20 -0500
Re: parsing print_r() output with preg_match_all() Ian Collins <ian-news@hotmail.com> - 2016-01-14 12:14 +1300
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 19:18 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 08:34 +0100
Re: parsing print_r() output with preg_match_all() Anders Wegge Keller <wegge@geostat.dk> - 2016-01-14 09:20 +0100
Re: parsing print_r() output with preg_match_all() Ian Collins <ian-news@hotmail.com> - 2016-01-14 21:56 +1300
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-14 16:08 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 22:55 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-14 16:59 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 23:09 +0100
Re: parsing print_r() output with preg_match_all() Ian Collins <ian-news@hotmail.com> - 2016-01-15 11:17 +1300
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-14 19:15 -0500
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-14 19:14 -0500
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 20:50 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 05:42 +0100
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-12 08:41 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 09:13 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 21:44 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 16:13 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 22:29 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 16:33 -0500
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-12 00:49 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 20:54 -0500
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 11:17 +0100
Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 13:49 +0100
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 14:20 +0100
Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 15:31 +0100
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 16:00 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-07 13:45 -0500
Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 20:18 +0100
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 20:52 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-07 15:29 -0500
Re: parsing print_r() output with preg_match_all() Tim Streater <timstreater@greenbee.net> - 2016-01-07 22:42 +0000
Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-08 10:43 +0100
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 09:07 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 08:05 -0500
Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 23:51 +0100
Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-12 00:31 +0100
Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 20:55 -0500
Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-12 11:11 +0100
Re: parsing print_r() output with preg_match_all() - question remains unanswered ... "R.Wieser" <address@not.available> - 2016-01-12 11:54 +0100
Re: parsing print_r() output with preg_match_all() - question remains unanswered ... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-12 11:25 +0000
Re: parsing print_r() output with preg_match_all() - question remains unanswered ... "R.Wieser" <address@not.available> - 2016-01-12 13:41 +0100
Re: parsing print_r() output with preg_match_all() - question remains unanswered ... "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-01-12 14:11 +0100
Re: parsing print_r() output with preg_match_all() - question remainsunanswered ... "R.Wieser" <address@not.available> - 2016-01-12 14:34 +0100
Re: parsing print_r() output with preg_match_all() - question remainsunanswered ... "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-01-12 15:03 +0100
Re: parsing print_r() output with preg_match_all() - questionremainsunanswered ... "R.Wieser" <address@not.available> - 2016-01-12 15:50 +0100
Re: parsing print_r() output with preg_match_all() - questionremainsunanswered ... "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-01-12 16:36 +0100
Re: parsing print_r() output with preg_match_all() - Solved. "R.Wieser" <address@not.available> - 2016-01-12 21:28 +0100
Re: parsing print_r() output with preg_match_all() - question remains unanswered ... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-12 14:02 +0000
Re: parsing print_r() output with preg_match_all() - question remains unanswered ... "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-01-12 12:42 +0100
Re: parsing print_r() output with preg_match_all() - question remainsunanswered ... "R.Wieser" <address@not.available> - 2016-01-12 14:20 +0100
Re: parsing print_r() output with preg_match_all() - question remains unanswered ... Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 09:43 -0500
Re: parsing print_r() output with preg_match_all() - question remainsunanswered ... "R.Wieser" <address@not.available> - 2016-01-12 16:11 +0100
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-01-07 14:05 +0000 |
| Message-ID | <87poxdwkl7.fsf@bsb.me.uk> |
| In reply to | #16139 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 1/7/2016 4:03 AM, R.Wieser wrote: >> Jerry, >> >>> XML comes to mind. Human readable and made to >>> be easily parsed. >> >> Its also like shooting a cannon at a musquito. :-) <snip> > > Not really. It's exactly the type of job XML was designed for. And it > is easily created and read. These things are all relative. If, as I now suspect, a simple json_encode and json_decode call will do the job, XML is going to look over the top unless there's an xml_encode and xml_decode pair that can serialise standard PHP types (I'm not up-to-date with the latest PHP but I could not find such functions). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-01-07 13:42 -0500 |
| Message-ID | <n6mbdq$o41$1@jstuckle.eternal-september.org> |
| In reply to | #16142 |
On 1/7/2016 9:05 AM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 1/7/2016 4:03 AM, R.Wieser wrote: >>> Jerry, >>> >>>> XML comes to mind. Human readable and made to >>>> be easily parsed. >>> >>> Its also like shooting a cannon at a musquito. :-) > <snip> >> >> Not really. It's exactly the type of job XML was designed for. And it >> is easily created and read. > > These things are all relative. If, as I now suspect, a simple > json_encode and json_decode call will do the job, XML is going to look > over the top unless there's an xml_encode and xml_decode pair that can > serialise standard PHP types (I'm not up-to-date with the latest PHP but > I could not find such functions). > There are any number of ways to implement XML in PHP. Encoding is as simple as a loop and/or recursive function. The result is a document compatible with the DOM and XML libraries. Not hard at all, once you've created a couple of XML documents. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-01-07 20:24 +0000 |
| Message-ID | <87egdtt9xt.fsf@bsb.me.uk> |
| In reply to | #16151 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 1/7/2016 9:05 AM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 1/7/2016 4:03 AM, R.Wieser wrote: >>>> Jerry, >>>> >>>>> XML comes to mind. Human readable and made to >>>>> be easily parsed. >>>> >>>> Its also like shooting a cannon at a musquito. :-) >> <snip> >>> >>> Not really. It's exactly the type of job XML was designed for. And it >>> is easily created and read. >> >> These things are all relative. If, as I now suspect, a simple >> json_encode and json_decode call will do the job, XML is going to look >> over the top unless there's an xml_encode and xml_decode pair that can >> serialise standard PHP types (I'm not up-to-date with the latest PHP but >> I could not find such functions). > > There are any number of ways to implement XML in PHP. Encoding is as > simple as a loop and/or recursive function. The result is a document > compatible with the DOM and XML libraries. If there are no XML equivalents of json_(en|de)code then it's harder. How much harder is governed by more than just how simple it is in XML -- the other part of the calculation is how very simple it is with JSON. To use a naive measure (don't take this too literally) if it's 2 lines using XML, it's twice as hard as it using JSON. I don't know for sure because, whilst I've now checked how it works using JSON, I've not done it with XML but I'd bet it's more than a line or two each way. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-01-07 15:27 -0500 |
| Message-ID | <n6mhim$jhi$1@jstuckle.eternal-september.org> |
| In reply to | #16156 |
On 1/7/2016 3:24 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 1/7/2016 9:05 AM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 1/7/2016 4:03 AM, R.Wieser wrote: >>>>> Jerry, >>>>> >>>>>> XML comes to mind. Human readable and made to >>>>>> be easily parsed. >>>>> >>>>> Its also like shooting a cannon at a musquito. :-) >>> <snip> >>>> >>>> Not really. It's exactly the type of job XML was designed for. And it >>>> is easily created and read. >>> >>> These things are all relative. If, as I now suspect, a simple >>> json_encode and json_decode call will do the job, XML is going to look >>> over the top unless there's an xml_encode and xml_decode pair that can >>> serialise standard PHP types (I'm not up-to-date with the latest PHP but >>> I could not find such functions). >> >> There are any number of ways to implement XML in PHP. Encoding is as >> simple as a loop and/or recursive function. The result is a document >> compatible with the DOM and XML libraries. > > If there are no XML equivalents of json_(en|de)code then it's harder. > How much harder is governed by more than just how simple it is in XML -- > the other part of the calculation is how very simple it is with JSON. > To use a naive measure (don't take this too literally) if it's 2 lines > using XML, it's twice as hard as it using JSON. I don't know for sure > because, whilst I've now checked how it works using JSON, I've not done > it with XML but I'd bet it's more than a line or two each way. > > <snip> > Not a lot more code. But whatever works for you. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2016-01-07 09:51 +0100 |
| Message-ID | <568e2b23$0$23766$e4fe514c@news.xs4all.nl> |
| In reply to | #16118 |
Ben, > Well the output of serialise is human-readable (just about). It cannot hurt to take a look at how it works and looks. > If it's always going to be just an array of arrays of strings, > you could design your own human-readable format whilst > making it (much) easier to read back. Thats very possible. Currently I'm trying some code to just parse the print_r() output, starting with exploding the data into its lines. I just tought it would be a good idea to try to use/adapt something which already worked. And you're right, I only storing simple (one-line) strings. Regards, Rudy Wieser -- Origional message: Ben Bacarisse <ben.usenet@bsb.me.uk> schreef in berichtnieuws 87fuyaza37.fsf@bsb.me.uk... > "R.Wieser" <address@not.available> writes: > > >> It would be a lot simpler if you could switch to using > >> serialize and unserialize. Do you need to use print_r > >> for some other reason? > > > > I'm using it to store the array-of-arrays into a file in human-readable > > format. I intend to parse this file using another program, posibly alter > > some info and write it back. > > Well the output of serialise is human-readable (just about). It's not > ideal, but then parsing print_r output is not ideal either. In fact, > it's not even possible in all cases though you may be able to make > enough assumptions about what's in the strings to get away with it. > > But I would seriously consider some other plan. If it's always going to > be just an array of arrays of strings, you could design your own > human-readable format whilst making it (much) easier to read back. > > <snip> > -- > Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-01-07 11:18 +0000 |
| Message-ID | <87egdty6xc.fsf@bsb.me.uk> |
| In reply to | #16127 |
"R.Wieser" <address@not.available> writes:
> Ben,
>
>> Well the output of serialise is human-readable (just about).
>
> It cannot hurt to take a look at how it works and looks.
>
>> If it's always going to be just an array of arrays of strings,
>> you could design your own human-readable format whilst
>> making it (much) easier to read back.
>
> Thats very possible. Currently I'm trying some code to just parse the
> print_r() output, starting with exploding the data into its lines.
> I just tought it would be a good idea to try to use/adapt something which
> already worked.
>
> And you're right, I only storing simple (one-line) strings.
If you put each string on a line and separate the arrays with a blank
line you can read it back using
array_map(function ($s) { return explode("\n", $s); },
explode("\n\n", get_file_contents($filename)));
though you may need to do some white space trimming, and if you can't
assume anonymous functions, it's hardly much longer. Of course, you
then can't extend the format and you might need to document it...
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2016-01-07 14:00 +0100 |
| Message-ID | <568e60e3$1$23768$e4fe514c@news.xs4all.nl> |
| In reply to | #16133 |
Ben,
> If you put each string on a line and separate the
> arrays with a blank line
I'm sorry, I should have said that its a mix of named, and indexed strings
and sub-arrays (as shown in my initial post)
Currently I'm parsing the data with an explode and a few normal comparisions
and a preg_match().
Although the result it looks well when its displayed by print_r(),
var_dump() shows most sub-arrays being prefixed with an "&" (oddly, not
all). I guess I'm having troubles with using arrays "by reference" ...
Regards,
Rudy Wieser
-- Origional message:
Ben Bacarisse <ben.usenet@bsb.me.uk> schreef in berichtnieuws
87egdty6xc.fsf@bsb.me.uk...
> "R.Wieser" <address@not.available> writes:
>
> > Ben,
> >
> >> Well the output of serialise is human-readable (just about).
> >
> > It cannot hurt to take a look at how it works and looks.
> >
> >> If it's always going to be just an array of arrays of strings,
> >> you could design your own human-readable format whilst
> >> making it (much) easier to read back.
> >
> > Thats very possible. Currently I'm trying some code to just parse the
> > print_r() output, starting with exploding the data into its lines.
> > I just tought it would be a good idea to try to use/adapt something
which
> > already worked.
> >
> > And you're right, I only storing simple (one-line) strings.
>
> If you put each string on a line and separate the arrays with a blank
> line you can read it back using
>
> array_map(function ($s) { return explode("\n", $s); },
> explode("\n\n", get_file_contents($filename)));
>
> though you may need to do some white space trimming, and if you can't
> assume anonymous functions, it's hardly much longer. Of course, you
> then can't extend the format and you might need to document it...
>
> <snip>
> --
> Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-01-07 14:00 +0000 |
| Message-ID | <87vb75wkts.fsf@bsb.me.uk> |
| In reply to | #16135 |
"R.Wieser" <address@not.available> writes: >> If you put each string on a line and separate the >> arrays with a blank line > > I'm sorry, I should have said that its a mix of named, and indexed strings > and sub-arrays (as shown in my initial post) > > Currently I'm parsing the data with an explode and a few normal comparisions > and a preg_match(). I think pretty-printed JSON is going to be the winner here. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2016-01-07 16:19 +0100 |
| Message-ID | <568e819c$0$23774$e4fe514c@news.xs4all.nl> |
| In reply to | #16135 |
> Although the result it looks well when its displayed by > print_r(), var_dump() shows most sub-arrays being > prefixed with an "&" (oddly, not all). I guess I'm having > troubles with using arrays "by reference" ... Turns out I wrongly assumed that a function-local array (used to store the currently used branch of arrays) would disappear after leaving the function (and thereby releasing its "by reference" stored array links in it). The answer I found on google (while looking for the exact meaning of that prefixed "&" in the var_dump() output) was to unlink() the "by reference" stored array after I was done with it (when encountering a ")" bracket). That means I now have some working code for my simple-strings array tree. :-) I would still like to know if the preg_match_all() function can be used to look for two-or-more different matches though ... Regards, Rudy Wieser -- Origional message: R.Wieser <address@not.available> schreef in berichtnieuws 568e60e3$1$23768$e4fe514c@news.xs4all.nl... > Ben, > > > If you put each string on a line and separate the > > arrays with a blank line > > I'm sorry, I should have said that its a mix of named, and indexed strings > and sub-arrays (as shown in my initial post) > > Currently I'm parsing the data with an explode and a few normal comparisions > and a preg_match(). > > Although the result it looks well when its displayed by print_r(), > var_dump() shows most sub-arrays being prefixed with an "&" (oddly, not > all). I guess I'm having troubles with using arrays "by reference" ... > > Regards, > Rudy Wieser
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2016-01-11 09:11 +0100 |
| Message-ID | <569363A3.6040108@arnowelzel.de> |
| In reply to | #16114 |
R.Wieser schrieb am 2016-01-06 um 20:50: > Ben, > >> It would be a lot simpler if you could switch to using >> serialize and unserialize. Do you need to use print_r >> for some other reason? > > I'm using it to store the array-of-arrays into a file in human-readable > format. I intend to parse this file using another program, posibly alter > some info and write it back. > > And thats the point where I wanted to use that regex to read the structure > back in. > > Now you mention it, I've heard from serializing and unserializing, but > was/am assuming that its not really ment to be read/understood by humans. > > But what's the problem with using that preg_match_all() ? It's prone to errors to build a parser on your own and there are already working and tested(!) solutions. May JSON is a good alternative for you: <http://php.net/manual/en/function.json-encode.php> <http://php.net/manual/en/function.json-decode.php> JSON is still "human readable" but also a defined format and there are parsers for other programming languages as well. -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-01-11 08:04 -0500 |
| Message-ID | <n70943$cp0$3@jstuckle.eternal-september.org> |
| In reply to | #16171 |
On 1/11/2016 3:11 AM, Arno Welzel wrote: > R.Wieser schrieb am 2016-01-06 um 20:50: > >> Ben, >> >>> It would be a lot simpler if you could switch to using >>> serialize and unserialize. Do you need to use print_r >>> for some other reason? >> >> I'm using it to store the array-of-arrays into a file in human-readable >> format. I intend to parse this file using another program, posibly alter >> some info and write it back. >> >> And thats the point where I wanted to use that regex to read the structure >> back in. >> >> Now you mention it, I've heard from serializing and unserializing, but >> was/am assuming that its not really ment to be read/understood by humans. >> >> But what's the problem with using that preg_match_all() ? > > It's prone to errors to build a parser on your own and there are already > working and tested(!) solutions. > > May JSON is a good alternative for you: > > <http://php.net/manual/en/function.json-encode.php> > <http://php.net/manual/en/function.json-decode.php> > > JSON is still "human readable" but also a defined format and there are > parsers for other programming languages as well. > > Gee, who built the parsers we have? Machines? ROFLMAO! It's not easy - but not everyone is as incompetent as you are, Arno. In fact, most people are much more competent. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2016-01-11 23:48 +0100 |
| Message-ID | <5694313D.3060100@arnowelzel.de> |
| In reply to | #16175 |
Jerry Stuckle schrieb am 2016-01-11 um 14:04: > On 1/11/2016 3:11 AM, Arno Welzel wrote: >> R.Wieser schrieb am 2016-01-06 um 20:50: >> >>> Ben, >>> >>>> It would be a lot simpler if you could switch to using >>>> serialize and unserialize. Do you need to use print_r >>>> for some other reason? >>> >>> I'm using it to store the array-of-arrays into a file in human-readable >>> format. I intend to parse this file using another program, posibly alter >>> some info and write it back. >>> >>> And thats the point where I wanted to use that regex to read the structure >>> back in. >>> >>> Now you mention it, I've heard from serializing and unserializing, but >>> was/am assuming that its not really ment to be read/understood by humans. >>> >>> But what's the problem with using that preg_match_all() ? >> >> It's prone to errors to build a parser on your own and there are already >> working and tested(!) solutions. >> >> May JSON is a good alternative for you: >> >> <http://php.net/manual/en/function.json-encode.php> >> <http://php.net/manual/en/function.json-decode.php> >> >> JSON is still "human readable" but also a defined format and there are >> parsers for other programming languages as well. >> >> > > Gee, who built the parsers we have? Machines? ROFLMAO! No - but there are *standards* you can refer to which are usually way better then trying to invent the wheel over and over again. > It's not easy - but not everyone is as incompetent as you are, Arno. In > fact, most people are much more competent. I know you have your problems with standards. You don't have to emphasize this all the time over and over again. -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2016-01-12 00:41 +0100 |
| Message-ID | <6929015.zlp62RpN2j@PointedEars.de> |
| In reply to | #16184 |
Arno Welzel wrote: > Jerry Stuckle schrieb am 2016-01-11 um 14:04: >> On 1/11/2016 3:11 AM, Arno Welzel wrote: >>> JSON is still "human readable" but also a defined format and there are >>> parsers for other programming languages as well. >> >> Gee, who built the parsers we have? Machines? ROFLMAO! So much for having trouble reading. Arno was referring to the *format* with “human *readable*” (as did the OP). BTW, if machines could build parsers (and machines *can* build parsers from rules written by a person [1], with Bison and Yacc probably being the best known), they could build them for human-readable *formats*, too. [1] <https://en.wikipedia.org/wiki/Compiler-compiler> > No - but there are *standards* you can refer to which are usually way > better then trying to invent the wheel over and over again. Full ACK. -- PointedEars Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-01-11 20:53 -0500 |
| Message-ID | <n71m57$tv4$1@jstuckle.eternal-september.org> |
| In reply to | #16187 |
On 1/11/2016 6:41 PM, Thomas 'Pointed Head' Lahn wrote: > Arno Welzel wrote: > >> Jerry Stuckle schrieb am 2016-01-11 um 14:04: >>> On 1/11/2016 3:11 AM, Arno Welzel wrote: >>>> JSON is still "human readable" but also a defined format and there are >>>> parsers for other programming languages as well. >>> >>> Gee, who built the parsers we have? Machines? ROFLMAO! > > So much for having trouble reading. Arno was referring to the *format* with > “human *readable*” (as did the OP). BTW, if machines could build parsers > (and machines *can* build parsers from rules written by a person [1], with > Bison and Yacc probably being the best known), they could build them for > human-readable *formats*, too. > And who builds the rules? I'm referring to the "human *readable*" format - just as the op did. But you don't understand the problems - just like the other troll does. > [1] <https://en.wikipedia.org/wiki/Compiler-compiler> > >> No - but there are *standards* you can refer to which are usually way >> better then trying to invent the wheel over and over again. > > Full ACK. > > You wouldn't know what a *real* standard is. All you know is the "standards according to Pointed Head" - which are acknowledged by exactly one person - YOU. As has been proven in multiple newsgroups. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2016-01-12 05:40 +0100 |
| Message-ID | <569483AF.6010606@arnowelzel.de> |
| In reply to | #16192 |
Jerry Stuckle schrieb am 2016-01-12 um 02:53: [...] > I'm referring to the "human *readable*" format - just as the op did. > But you don't understand the problems - just like the other troll does. JSON *is* human readable. Do you even know what JSON is? If not - here is the official standard: ECMA-404 - The JSON Data Interchange Format <http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf> "JSON is a lightweight, text-based, language-independent data interchange format." -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-01-12 09:12 -0500 |
| Message-ID | <n731fa$5dh$1@jstuckle.eternal-september.org> |
| In reply to | #16196 |
On 1/11/2016 11:40 PM, Arno Welzel wrote: > Jerry Stuckle schrieb am 2016-01-12 um 02:53: > > [...] >> I'm referring to the "human *readable*" format - just as the op did. >> But you don't understand the problems - just like the other troll does. > > JSON *is* human readable. Do you even know what JSON is? > > If not - here is the official standard: > > ECMA-404 - The JSON Data Interchange Format > > <http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf> > > "JSON is a lightweight, text-based, language-independent data > interchange format." > > > I know exactly what JSON is, troll. And while it *can* be read, it's not very obvious unless you already know what you're looking for. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2016-01-12 21:43 +0100 |
| Message-ID | <56956576.3040909@arnowelzel.de> |
| In reply to | #16211 |
Jerry Stuckle schrieb am 2016-01-12 um 15:12: > On 1/11/2016 11:40 PM, Arno Welzel wrote: >> Jerry Stuckle schrieb am 2016-01-12 um 02:53: >> >> [...] >>> I'm referring to the "human *readable*" format - just as the op did. >>> But you don't understand the problems - just like the other troll does. >> >> JSON *is* human readable. Do you even know what JSON is? >> >> If not - here is the official standard: >> >> ECMA-404 - The JSON Data Interchange Format >> >> <http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf> >> >> "JSON is a lightweight, text-based, language-independent data >> interchange format." >> >> >> > > I know exactly what JSON is, troll. And while it *can* be read, it's > not very obvious unless you already know what you're looking for. If you know JSON then why don't you see it as a standard, old grey bearded man? And "human readable" generally means it is *text* which can be easily opened using any kind of text editor and you can see the general structure there. If you describe XML as "human readable" as in <n6k0a5$od7$1@jstuckle.eternal-september.org> then JSON also falls into this category - since XML can be quite confusing as well. -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-01-12 16:12 -0500 |
| Message-ID | <n73q38$bba$1@jstuckle.eternal-september.org> |
| In reply to | #16223 |
On 1/12/2016 3:43 PM, Arno Welzel wrote: > Jerry Stuckle schrieb am 2016-01-12 um 15:12: >> On 1/11/2016 11:40 PM, Arno Welzel wrote: >>> Jerry Stuckle schrieb am 2016-01-12 um 02:53: >>> >>> [...] >>>> I'm referring to the "human *readable*" format - just as the op did. >>>> But you don't understand the problems - just like the other troll does. >>> >>> JSON *is* human readable. Do you even know what JSON is? >>> >>> If not - here is the official standard: >>> >>> ECMA-404 - The JSON Data Interchange Format >>> >>> <http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf> >>> >>> "JSON is a lightweight, text-based, language-independent data >>> interchange format." >>> >>> >>> >> >> I know exactly what JSON is, troll. And while it *can* be read, it's >> not very obvious unless you already know what you're looking for. > > If you know JSON then why don't you see it as a standard, old grey > bearded man? > I never said it wasn't a standard, troll. But you keep trying to put words in my mouth. All it does is show your stoopidity. > And "human readable" generally means it is *text* which can be easily > opened using any kind of text editor and you can see the general > structure there. > > If you describe XML as "human readable" as in > <n6k0a5$od7$1@jstuckle.eternal-september.org> then JSON also falls into > this category - since XML can be quite confusing as well. > > xml can be quite a bit easier to read and understand - if you do it correctly. But you wouldn't know. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2016-01-12 22:28 +0100 |
| Message-ID | <56956FF5.3050603@arnowelzel.de> |
| In reply to | #16225 |
Jerry Stuckle schrieb am 2016-01-12 um 22:12: > On 1/12/2016 3:43 PM, Arno Welzel wrote: >> Jerry Stuckle schrieb am 2016-01-12 um 15:12: >>> On 1/11/2016 11:40 PM, Arno Welzel wrote: >>>> Jerry Stuckle schrieb am 2016-01-12 um 02:53: >>>> >>>> [...] >>>>> I'm referring to the "human *readable*" format - just as the op did. >>>>> But you don't understand the problems - just like the other troll does. >>>> >>>> JSON *is* human readable. Do you even know what JSON is? >>>> >>>> If not - here is the official standard: >>>> >>>> ECMA-404 - The JSON Data Interchange Format >>>> >>>> <http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf> >>>> >>>> "JSON is a lightweight, text-based, language-independent data >>>> interchange format." >>>> >>>> >>>> >>> >>> I know exactly what JSON is, troll. And while it *can* be read, it's >>> not very obvious unless you already know what you're looking for. >> >> If you know JSON then why don't you see it as a standard, old grey >> bearded man? >> > > I never said it wasn't a standard, troll. But you keep trying to put > words in my mouth. All it does is show your stoopidity. No - but you say I don't know what a standard is - just based in the fact that I mentioned JSON as a standard. So I must assume you believe JSON is not a standard. >> And "human readable" generally means it is *text* which can be easily >> opened using any kind of text editor and you can see the general >> structure there. >> >> If you describe XML as "human readable" as in >> <n6k0a5$od7$1@jstuckle.eternal-september.org> then JSON also falls into >> this category - since XML can be quite confusing as well. >> >> > > xml can be quite a bit easier to read and understand - if you do it > correctly. But you wouldn't know. The same is true for JSON - but you don't know. -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-01-12 16:35 -0500 |
| Message-ID | <n73rd0$goq$2@jstuckle.eternal-september.org> |
| In reply to | #16228 |
On 1/12/2016 4:28 PM, Arno Welzel wrote: > Jerry Stuckle schrieb am 2016-01-12 um 22:12: > >> On 1/12/2016 3:43 PM, Arno Welzel wrote: >>> Jerry Stuckle schrieb am 2016-01-12 um 15:12: >>>> On 1/11/2016 11:40 PM, Arno Welzel wrote: >>>>> Jerry Stuckle schrieb am 2016-01-12 um 02:53: >>>>> >>>>> [...] >>>>>> I'm referring to the "human *readable*" format - just as the op did. >>>>>> But you don't understand the problems - just like the other troll does. >>>>> >>>>> JSON *is* human readable. Do you even know what JSON is? >>>>> >>>>> If not - here is the official standard: >>>>> >>>>> ECMA-404 - The JSON Data Interchange Format >>>>> >>>>> <http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf> >>>>> >>>>> "JSON is a lightweight, text-based, language-independent data >>>>> interchange format." >>>>> >>>>> >>>>> >>>> >>>> I know exactly what JSON is, troll. And while it *can* be read, it's >>>> not very obvious unless you already know what you're looking for. >>> >>> If you know JSON then why don't you see it as a standard, old grey >>> bearded man? >>> >> >> I never said it wasn't a standard, troll. But you keep trying to put >> words in my mouth. All it does is show your stoopidity. > > No - but you say I don't know what a standard is - just based in the > fact that I mentioned JSON as a standard. > > So I must assume you believe JSON is not a standard. > Once again you're trying to put words in my mouth, troll. But you're just showing how stoopid you are. >>> And "human readable" generally means it is *text* which can be easily >>> opened using any kind of text editor and you can see the general >>> structure there. >>> >>> If you describe XML as "human readable" as in >>> <n6k0a5$od7$1@jstuckle.eternal-september.org> then JSON also falls into >>> this category - since XML can be quite confusing as well. >>> >>> >> >> xml can be quite a bit easier to read and understand - if you do it >> correctly. But you wouldn't know. > > The same is true for JSON - but you don't know. > > No, you have no control over the format of JSON. You have a great deal of control over the format of XML. But you obviously are too stoopid to understand that. How like a troll. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.php
csiph-web