This list is closed, nobody may subscribe to it.
2010 |
Jan
(57) |
Feb
(65) |
Mar
(1) |
Apr
(35) |
May
(5) |
Jun
(10) |
Jul
(6) |
Aug
(85) |
Sep
(56) |
Oct
(15) |
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(12) |
Feb
(65) |
Mar
(13) |
Apr
(1) |
May
|
Jun
(3) |
Jul
|
Aug
(102) |
Sep
(390) |
Oct
(175) |
Nov
(284) |
Dec
(203) |
2012 |
Jan
(172) |
Feb
(289) |
Mar
(277) |
Apr
(178) |
May
(141) |
Jun
(136) |
Jul
(146) |
Aug
(109) |
Sep
(257) |
Oct
(240) |
Nov
(150) |
Dec
(122) |
2013 |
Jan
(257) |
Feb
(179) |
Mar
(264) |
Apr
(244) |
May
(178) |
Jun
(268) |
Jul
(153) |
Aug
(177) |
Sep
(188) |
Oct
(185) |
Nov
(280) |
Dec
(81) |
2014 |
Jan
(90) |
Feb
(221) |
Mar
(211) |
Apr
(235) |
May
(79) |
Jun
(210) |
Jul
(122) |
Aug
(136) |
Sep
(188) |
Oct
(184) |
Nov
(151) |
Dec
(179) |
2015 |
Jan
(83) |
Feb
(145) |
Mar
(51) |
Apr
(66) |
May
(37) |
Jun
(243) |
Jul
(51) |
Aug
(133) |
Sep
(327) |
Oct
(112) |
Nov
(41) |
Dec
(55) |
2016 |
Jan
(167) |
Feb
(166) |
Mar
(192) |
Apr
(31) |
May
(52) |
Jun
(91) |
Jul
(201) |
Aug
(141) |
Sep
(74) |
Oct
(20) |
Nov
(18) |
Dec
(20) |
2017 |
Jan
(18) |
Feb
(40) |
Mar
(31) |
Apr
(87) |
May
(44) |
Jun
(41) |
Jul
(377) |
Aug
(203) |
Sep
(141) |
Oct
(256) |
Nov
(387) |
Dec
(240) |
2018 |
Jan
(19) |
Feb
(241) |
Mar
(248) |
Apr
(115) |
May
(65) |
Jun
(68) |
Jul
(115) |
Aug
(28) |
Sep
(44) |
Oct
(174) |
Nov
(37) |
Dec
(10) |
2019 |
Jan
(15) |
Feb
|
Mar
(95) |
Apr
(7) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Matej S. <mat...@co...> - 2012-03-07 14:51:01
|
I was asking myself the same question... Who's the "boss"? Matej |
From: Dalesio, L. <da...@bn...> - 2012-03-07 14:49:22
|
No meeting today - right? -----Original Message----- From: Matej Sekoranja [mailto:mat...@co...] Sent: Wednesday, March 07, 2012 9:44 AM To: Marty Kraimer Cc: epi...@li... Subject: Re: Is it OK to commit changes to pvIOCCPP? > What do I do? > > Do I want to > > hg merge tip > > ??? Yes. Matej ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ |
From: Matej S. <mat...@co...> - 2012-03-07 14:43:41
|
> What do I do? > > Do I want to > > hg merge tip > > ??? Yes. Matej |
From: <dav...@di...> - 2012-03-07 14:43:37
|
I don't think making getFieldName() a member of PVField is really any better than making getName() a member of Field. The "fieldname" is used to reference a member of a structure. It is a property of the structure or perhaps the a member object that belongs to the structure. It isn't a property of the Field. It isn't a property of the PVField. It's a property of the structure. Therefore it shouldn't be in the Field or the PVField. It should be in the structure or some constituent part of it. When you write "or an empty string if it is a top level field" this should be a clue that something's amiss. The fieldname in a top level structure or for the structure underlying a StructureArray has no meaning. This shows us that the design isn't quite right. If you make the fieldname a property of the struct it's present if and only if it has meaning. Regards, Dave. Dr David Hickin Software Systems Engineer (EPICS) Diamond Light Source Ltd Diamond House Harwell Science & Innovation Campus Didcot, Oxfordshire, OX11 0DE -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom -----Original Message----- From: Marty Kraimer [mailto:mrk...@co...] Sent: 07 March 2012 11:22 To: epi...@li... Subject: Re: Move location of fieldName from Field to Structure On 03/06/2012 04:16 PM, Andrew Johnson wrote: > Hi Marty, > > On 2012-03-06 Marty Kraimer wrote: >> Instead this becomes: >> >> public boolean attach(PVField pvField) { >> PVStructure pvStructure = null; >> >> if(!pvField.getParent().getFieldName(pvField).equals("control")) >> { >> >> if(!pvField.getParent().getFieldName(pvField).equals("value")) { >> ... >> >> Thus even more simple and more efficient. > It looks to me like PVField could have a convenience method > getOwnName() or even just getName() I would make getFieldName() a method of PVField Thus PVField has additional method: String getFieldName(); // returns the name of the PVField itself or an empty string if it is a top level field If we have this then PVStructure::getFieldName(PVField pvField) does not appear to be necessary. Thus only have PVField::getFieldName(); Structure still has methods: String[] getFieldNames() Field[] getFields(); > if that's not already used, which just does: > > return this.getParent().getFieldName(this); > > With that your example gets even shorter: > > public boolean attach(PVField pvField) { > PVStructure pvStructure = null; > > if (!pvField.getName().equals("control")) > { ... } > if (!pvField.getName().equals("value")) > { ... } > > What do top-level PVField objects do in getParent()? return null. Another argument for PVField::getFieldName() instead of PVStructure::getFieldName(PVField pvField) With this Andrews example works except for getFieldName instead of getName. I do not like just getName because it is too generic. If everything uses getName instead of some context specific name like getXXXName then it becomes really hard to use grep to look for problems. Marty > > - Andrew ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |
From: Marty K. <mrk...@co...> - 2012-03-07 14:38:34
|
On 03/07/2012 09:07 AM, Shen, Guobao wrote: > Hi Marty, > James already tagged the snapshot and beta release 2 months ago. > There has no changes in source codes, but some clean up in the configuration files. > > I would suggest to check it in. I get: mrk> hg merge abort: branch 'default' has 3 heads - please merge with an explicit rev (run 'hg heads .' to see heads) mrk> hg heads changeset: 93:c65abc39fa07 tag: tip user: Guobao Shen date: Tue Mar 06 21:01:54 2012 -0500 summary: remove site specific configuration changeset: 91:7be9c5720396 user: Marty Kraimer <mrk...@co...> date: Wed Mar 07 09:34:53 2012 -0500 summary: fix bug in pvServicwProvider that causes termination problems changeset: 46:e6abf140a3b9 user: Matej Sekoranja date: Thu May 19 09:14:52 2011 +0200 summary: shared pointers usage What do I do? Do I want to hg merge tip ??? Marty > By the way, what is the plan for next beta2 release? > > Guobao > > On 3/7/12 7:16 AM, Marty Kraimer wrote: >> Greg, >> >> While looking at possible memory leaks I found a problem when a RPC >> server terminates. >> I want to commit some changes to pvIOCCPP. >> Is this OK or does it affect beta releases? >> >> Marty >> >> ------------------------------------------------------------------------------ >> Virtualization& Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> |
From: <dav...@di...> - 2012-03-07 14:18:32
|
"Marty's proposal has the advantage of not needing an extra class for the (name,type) pair (for Java, where tuples are not supported). In C++ one could use pair<std::string,Field> but that, too, isn't exactly beautiful if you ask me,." I think what your suggesting for C++ is closer to Nikolay and my suggestions. In a standard pair you're grouping two objects together into a single object - you'd presumably then have containers of pairs. There's not much difference between a pair consisting of a string and a field and Nikolay's MemberDescriptor or my MemberField. The latter two are I think better from an OO point of view if they are to ever leave the internals of a class in that they have better encapsulation, they avoid public data, their implementation can be changed, they can be polymorphic etc, etc. If they don't leave then it doesn't matter - it's an implementation detail. Creating a member class might not be necessary, but it doesn't sound painful and classes should map to concepts in the system as much as possible and structs have members so it doesn't sound like a unreasonable class for us to have. Regards, Dave. Dr David Hickin Software Systems Engineer (EPICS) Diamond Light Source Ltd Diamond House Harwell Science & Innovation Campus Didcot, Oxfordshire, OX11 0DE -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom -----Original Message----- From: Benjamin Franksen [mailto:ben...@he...] Sent: 07 March 2012 13:59 To: epi...@li... Subject: Re: Move location of fieldName from Field to Structure On Wednesday, March 07, 2012, dav...@di... wrote: > >> It will bring the classical description of the composite type: > >> > >> 1. Structure has members > >> 2. Each member has name and type > > > >Remember that name and type not enough." > > I think there is confusion about the meaning of "type" here. As I > understand Nikolay's idean type means type in the generic sense, i.e. > what you've called field, but without the name not the numeric code in > a Field object. So it's a polymorphic object and scalars would have a > getScalarType() function. > > ">If so I think the following is better > > >interface Structure { > > > > String[] getFieldNames(); > > Field[] getFields(); > > > >}" > > I inclined to think Nikolay's is better. > In the same way that, for example, if you have a number of points it's > better to have an array of point objects than two arrays of x and y > coordinates. I would say that both are pretty much equivalent. Marty's proposal has the advantage of not needing an extra class for the (name,type) pair (for Java, where tuples are not supported). In C++ one could use pair<std::string,Field> but that, too, isn't exactly beautiful if you ask me,. Cheers Ben ________________________________ Helmholtz-Zentrum Berlin für Materialien und Energie GmbH Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V. Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph Geschäftsführerin: Prof. Dr. Anke Rita Kaysser-Pyzalla Sitz Berlin, AG Charlottenburg, 89 HRB 5583 Postadresse: Hahn-Meitner-Platz 1 D-14109 Berlin http://www.helmholtz-berlin.de ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |
From: Shen, G. <sh...@bn...> - 2012-03-07 14:09:10
|
Hi James, Get it. As you said, it would be a quick solution. I thought we have the same configuration for all modules, but it does not. Guobao On 3/7/12 3:18 AM, jam...@di... wrote: > Hi Guobao > > No there isn't, to fix the build temporarily put the site-specific information back into configure/RELEASE > > James > > ________________________________________ > From: Shen, Guobao [sh...@bn...] > Sent: 07 March 2012 02:07 > To: epi...@li... > Subject: FW: Build failed in Jenkins: pvIOCCPP - Build #224 > > Is there any RELEASE.local on JENKINS server for this module to avoid this build error? > > Guobao > ________________________________________ > From: Jenkins Build Server [no...@bn...] > Sent: Tuesday, March 06, 2012 9:03 PM > To: epi...@li... > Subject: Build failed in Jenkins: pvIOCCPP - Build #224 > > See<https://irmis-dev.bnl.gov/jenkins/job/pvIOCCPP%20-%20Build/224/changes> > > Changes: > > [Guobao Shen] remove site specific configuration > > ------------------------------------------ > Started by an SCM change > Building remotely on irmis-dev > [pvIOCCPP] $ hg incoming --quiet --bundle hg.bundle --template "<changeset node='{node}' author='{author|xmlescape}' rev='{rev}' date='{date}'><msg>{desc|xmlescape}</msg><added>{file_adds|stringify|xmlescape}</added><deleted>{file_dels|stringify|xmlescape}</deleted><files>{files|stringify|xmlescape}</files><parents>{parents}</parents></changeset>\n" --rev default > [pvIOCCPP] $ hg unbundle hg.bundle > adding changesets > adding manifests > adding file changes > added 1 changesets with 1 changes to 1 files > (run 'hg update' to get a working copy) > [pvIOCCPP] $ hg update --clean --rev default > 1 files updated, 0 files merged, 0 files removed, 0 files unresolved > [pvIOCCPP] $ hg log --rev . --template {node} > [pvIOCCPP] $ /bin/sh -xe /tmp/hudson7653968229631089287.sh > + cp configure/RELEASE configure/RELEASE.bak > + sed s/^EPICS_BASE=.*/EPICS_BASE=\/usr\/lib\/epics/ configure/RELEASE.bak > + sed s/^PVDATA=.*/PVDATA=\$\(TOP\)\/.\.\/pvDataCPP/ configure/RELEASE.tmp > + sed s/^PVACCESS=.*/PVACCESS=\$\(TOP\)\/.\.\/pvAccessCPP/ configure/RELEASE.tmp2 > + make clean all > configure/CONFIG:17: /configure/CONFIG: No such file or directory > configure/RULES_TOP:2: /configure/RULES_TOP: No such file or directory > make: *** No rule to make target `/configure/RULES_TOP'. Stop. > Build step 'Execute shell' marked build as failure > Build failed. Publishing Doxygen skipped. > > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > -- Guobao Shen Bldg. 902-B, 17 Cornell Avenue National Synchrotron Light Source II Brookhaven National Laboratory Upton, New York 11973 Tel. : +1 (631) 344 7540 Fax. : +1 (631) 344 8085 http://www.bnl.gov/nsls2 |
From: Shen, G. <sh...@bn...> - 2012-03-07 14:07:28
|
Hi Marty, James already tagged the snapshot and beta release 2 months ago. There has no changes in source codes, but some clean up in the configuration files. I would suggest to check it in. By the way, what is the plan for next beta2 release? Guobao On 3/7/12 7:16 AM, Marty Kraimer wrote: > Greg, > > While looking at possible memory leaks I found a problem when a RPC > server terminates. > I want to commit some changes to pvIOCCPP. > Is this OK or does it affect beta releases? > > Marty > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > -- Guobao Shen Bldg. 902-B, 17 Cornell Avenue National Synchrotron Light Source II Brookhaven National Laboratory Upton, New York 11973 Tel. : +1 (631) 344 7540 Fax. : +1 (631) 344 8085 http://www.bnl.gov/nsls2 |
From: Benjamin F. <ben...@he...> - 2012-03-07 13:59:39
|
On Wednesday, March 07, 2012, dav...@di... wrote: > >> It will bring the classical description of the composite type: > >> > >> 1. Structure has members > >> 2. Each member has name and type > > > >Remember that name and type not enough." > > I think there is confusion about the meaning of "type" here. As I > understand Nikolay's idean type means type in the generic sense, i.e. > what you've called field, but without the name not the numeric code in a > Field object. So it's a polymorphic object and scalars would have a > getScalarType() function. > > ">If so I think the following is better > > >interface Structure { > > > > String[] getFieldNames(); > > Field[] getFields(); > > > >}" > > I inclined to think Nikolay's is better. > In the same way that, for example, if you have a number of points it's > better to have an array of point objects than two arrays of x and y > coordinates. I would say that both are pretty much equivalent. Marty's proposal has the advantage of not needing an extra class for the (name,type) pair (for Java, where tuples are not supported). In C++ one could use pair<std::string,Field> but that, too, isn't exactly beautiful if you ask me,. Cheers Ben ________________________________ Helmholtz-Zentrum Berlin für Materialien und Energie GmbH Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V. Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph Geschäftsführerin: Prof. Dr. Anke Rita Kaysser-Pyzalla Sitz Berlin, AG Charlottenburg, 89 HRB 5583 Postadresse: Hahn-Meitner-Platz 1 D-14109 Berlin http://www.helmholtz-berlin.de |
From: Malitsky, N. D <mal...@bn...> - 2012-03-07 13:29:32
|
Dave, You are right. I forgot to explain that, in the pvData world, "type" is represented by a Field object. So, ideally, “Field” has to be replaced with “FieldType”, and “Type” with “TypeKind” -Nikolay ________________________________________ From: dav...@di... [dav...@di...] Sent: Wednesday, March 07, 2012 8:03 AM To: mrk...@co...; Malitsky, Nikolay D Cc: epi...@li... Subject: RE: Move location of fieldName from Field to Structure ">> >> It will bring the classical description of the composite type: >> >> 1. Structure has members >> 2. Each member has name and type >Remember that name and type not enough." I think there is confusion about the meaning of "type" here. As I understand Nikolay's idean type means type in the generic sense, i.e. what you've called field, but without the name not the numeric code in a Field object. So it's a polymorphic object and scalars would have a getScalarType() function. ">If so I think the following is better >interface Structure { > String[] getFieldNames(); > Field[] getFields(); >}" I inclined to think Nikolay's is better. In the same way that, for example, if you have a number of points it's better to have an array of point objects than two arrays of x and y coordinates. Oh, and apologies for Misspelling your name Nikolay :) Regards, Dave. Dr David Hickin Software Systems Engineer (EPICS) Diamond Light Source Ltd Diamond House Harwell Science & Innovation Campus Didcot, Oxfordshire, OX11 0DE -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom -----Original Message----- From: Marty Kraimer [mailto:mrk...@co...] Sent: 07 March 2012 12:48 To: Malitsky, Nikolay D Cc: epi...@li... Subject: Re: Move location of fieldName from Field to Structure On 03/05/2012 04:53 PM, Malitsky, Nikolay D wrote: > Marty, > > Since you are ready for changes, I would suggest to add MemberDescriptor. Sorry I do not know what you mean. Do you mean something like interface MemberDescriptor { String getName(); Field getField(); } interface Structure { MemberDescriptor[] getDescriptors(); ... } If so I think the following is better interface Structure { String[] getFieldNames(); Field[] getFields(); } Thus structure of arrays is better than array of structures. Greg taught this to me :-) Or did you mean something else? > > It will bring the classical description of the composite type: > > 1. Structure has members > 2. Each member has name and type Remember that name and type not enough. If type is scalar then also want scalarType. If type is scalarArray then also want scalarType for elements. If structureArray also want Structure for elements If structure also want "Field[] fields" and "String[] fieldNames" for subfields of Structure. Marty > > -Nikolay > > -----Original Message----- > From: Marty Kraimer [mailto:mrk...@co...] > Sent: Monday, March 05, 2012 4:22 PM > To: epi...@li... > Subject: Move location of fieldName from Field to Structure > > It appears that several people, at least David, Benjamin, Matej, and Andrew, think it is a mistake to make the fieldName belong to Field. > > How about the following: > > Currently Field and Structure are defined as folllows: > > public interface Field { > String getFieldName(); > Type getType(); > void toString(StringBuilder buf); > void toString(StringBuilder buf,int indentLevel); > String toString(); > } > public interface Structure extends Field{ > Field getField(String fieldName); > int getFieldIndex(String fieldName); > Field[] getFields(); > } > > Change this to: > > public interface Field { > Type getType(); > void toString(StringBuilder buf); > void toString(StringBuilder buf,int indentLevel); > String toString(); > } > public interface Structure extends Field{ > Field getField(String fieldName); > int getFieldIndex(String fieldName); > Field[] getFields(); > String getFieldName(Field field); > String[] getFieldNames(); > } > > There will also be some changes to FieldCreate and maybe to PVDataCreate. > > I looked for calls to getFieldName in the src tree for pvDataJava, pvAccessJava, and pvIOCJava and found: > > pvDataJava/src 39 calls > pvAccessJava/src 4 calls > pvIOCJava/src 43 calls. > > I looked at a few instances and see only minor changes in the code. > Thus it looks like it will not be a major effort to implement the above change. > > > Marty > > > ---------------------------------------------------------------------- > -------- Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft > developers is just $99.99! Visual Studio, SharePoint, SQL - plus > HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |
From: <dav...@di...> - 2012-03-07 13:04:26
|
">> >> It will bring the classical description of the composite type: >> >> 1. Structure has members >> 2. Each member has name and type >Remember that name and type not enough." I think there is confusion about the meaning of "type" here. As I understand Nikolay's idean type means type in the generic sense, i.e. what you've called field, but without the name not the numeric code in a Field object. So it's a polymorphic object and scalars would have a getScalarType() function. ">If so I think the following is better >interface Structure { > String[] getFieldNames(); > Field[] getFields(); >}" I inclined to think Nikolay's is better. In the same way that, for example, if you have a number of points it's better to have an array of point objects than two arrays of x and y coordinates. Oh, and apologies for Misspelling your name Nikolay :) Regards, Dave. Dr David Hickin Software Systems Engineer (EPICS) Diamond Light Source Ltd Diamond House Harwell Science & Innovation Campus Didcot, Oxfordshire, OX11 0DE -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom -----Original Message----- From: Marty Kraimer [mailto:mrk...@co...] Sent: 07 March 2012 12:48 To: Malitsky, Nikolay D Cc: epi...@li... Subject: Re: Move location of fieldName from Field to Structure On 03/05/2012 04:53 PM, Malitsky, Nikolay D wrote: > Marty, > > Since you are ready for changes, I would suggest to add MemberDescriptor. Sorry I do not know what you mean. Do you mean something like interface MemberDescriptor { String getName(); Field getField(); } interface Structure { MemberDescriptor[] getDescriptors(); ... } If so I think the following is better interface Structure { String[] getFieldNames(); Field[] getFields(); } Thus structure of arrays is better than array of structures. Greg taught this to me :-) Or did you mean something else? > > It will bring the classical description of the composite type: > > 1. Structure has members > 2. Each member has name and type Remember that name and type not enough. If type is scalar then also want scalarType. If type is scalarArray then also want scalarType for elements. If structureArray also want Structure for elements If structure also want "Field[] fields" and "String[] fieldNames" for subfields of Structure. Marty > > -Nikolay > > -----Original Message----- > From: Marty Kraimer [mailto:mrk...@co...] > Sent: Monday, March 05, 2012 4:22 PM > To: epi...@li... > Subject: Move location of fieldName from Field to Structure > > It appears that several people, at least David, Benjamin, Matej, and Andrew, think it is a mistake to make the fieldName belong to Field. > > How about the following: > > Currently Field and Structure are defined as folllows: > > public interface Field { > String getFieldName(); > Type getType(); > void toString(StringBuilder buf); > void toString(StringBuilder buf,int indentLevel); > String toString(); > } > public interface Structure extends Field{ > Field getField(String fieldName); > int getFieldIndex(String fieldName); > Field[] getFields(); > } > > Change this to: > > public interface Field { > Type getType(); > void toString(StringBuilder buf); > void toString(StringBuilder buf,int indentLevel); > String toString(); > } > public interface Structure extends Field{ > Field getField(String fieldName); > int getFieldIndex(String fieldName); > Field[] getFields(); > String getFieldName(Field field); > String[] getFieldNames(); > } > > There will also be some changes to FieldCreate and maybe to PVDataCreate. > > I looked for calls to getFieldName in the src tree for pvDataJava, pvAccessJava, and pvIOCJava and found: > > pvDataJava/src 39 calls > pvAccessJava/src 4 calls > pvIOCJava/src 43 calls. > > I looked at a few instances and see only minor changes in the code. > Thus it looks like it will not be a major effort to implement the above change. > > > Marty > > > ---------------------------------------------------------------------- > -------- Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft > developers is just $99.99! Visual Studio, SharePoint, SQL - plus > HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |
From: <dav...@di...> - 2012-03-07 12:52:51
|
If think Nicolay has the idea exactly right: "1. Structure has members 2. Each member has name and type" This is exactly what I've been suggesting is the correct solution. To implement this requires some work though. The fieldName goes from the Field and the structure has to have a named list of Fields. PVStructures have lists of PVs which you can look up by name. We may want to create a MemberField for the member fields of a structure and possibly also a MemberPVField object for the members of a PVStructure. I've only had an hour or so to see how this would work out though I'm happy to spend a bit more time on this now people are taking the idea seriously. But in the interests of getting something out before today's call here's my best shot at how this would work: 1. Remove the getName() from field. Also remove the name itself from implementations. 2. Create MemberField inteface with getName() and getField() functions. Create concrete BaseMemberField constructed from member name string. 3. In FieldCreate, Field create(String fieldName, Field field) should be replaced by MemberField createMember(String fieldName, Field field) the other create methods (createScalar and so on) should lose their fieldname string. CreateStructure should take an array of MemberFields. 4. Structure should have a getMembers() probably instead of instead of (but perhaps in addition to) getFields(). getFieldIndex could be renamed getMemberIndex (optional). getField() should remain the same. 5. May need MemberPVField interface and BaseMemberPVField impl with getName() and getPVField() methods. 6. In PVStructure need list of names and PVs (possible as MemberPVField objects) 7. In PVDataCreate appendPVField(PVField) needs replacing by appendPVField(String fieldName, PVField) (or appendMemberPVField(MemberPVField)). getPVFields() and getSubField() methods are probably correct as is as the the a common use is to use the string to look up the SubField and put or get May need getMemberPVFields in addition to or instead of or add a getNumberOFSubFields() to help iterate over members. 8. Types are serialized without the fieldname which doesn't exist. When you serialize a structure giving the full interface description, after writing the byte you serialize the members by serializing the fieldname and type. Regards, Dave. Dr David Hickin Software Systems Engineer (EPICS) Diamond Light Source Ltd Diamond House Harwell Science & Innovation Campus Didcot, Oxfordshire, OX11 0DE -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom -----Original Message----- From: Malitsky, Nikolay D [mailto:mal...@bn...] Sent: 05 March 2012 21:54 To: Marty Kraimer; epi...@li... Subject: RE: Move location of fieldName from Field to Structure Marty, Since you are ready for changes, I would suggest to add MemberDescriptor. It will bring the classical description of the composite type: 1. Structure has members 2. Each member has name and type -Nikolay -----Original Message----- From: Marty Kraimer [mailto:mrk...@co...] Sent: Monday, March 05, 2012 4:22 PM To: epi...@li... Subject: Move location of fieldName from Field to Structure It appears that several people, at least David, Benjamin, Matej, and Andrew, think it is a mistake to make the fieldName belong to Field. How about the following: Currently Field and Structure are defined as folllows: public interface Field { String getFieldName(); Type getType(); void toString(StringBuilder buf); void toString(StringBuilder buf,int indentLevel); String toString(); } public interface Structure extends Field{ Field getField(String fieldName); int getFieldIndex(String fieldName); Field[] getFields(); } Change this to: public interface Field { Type getType(); void toString(StringBuilder buf); void toString(StringBuilder buf,int indentLevel); String toString(); } public interface Structure extends Field{ Field getField(String fieldName); int getFieldIndex(String fieldName); Field[] getFields(); String getFieldName(Field field); String[] getFieldNames(); } There will also be some changes to FieldCreate and maybe to PVDataCreate. I looked for calls to getFieldName in the src tree for pvDataJava, pvAccessJava, and pvIOCJava and found: pvDataJava/src 39 calls pvAccessJava/src 4 calls pvIOCJava/src 43 calls. I looked at a few instances and see only minor changes in the code. Thus it looks like it will not be a major effort to implement the above change. Marty ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |
From: Marty K. <mrk...@co...> - 2012-03-07 12:48:24
|
On 03/05/2012 04:53 PM, Malitsky, Nikolay D wrote: > Marty, > > Since you are ready for changes, I would suggest to add MemberDescriptor. Sorry I do not know what you mean. Do you mean something like interface MemberDescriptor { String getName(); Field getField(); } interface Structure { MemberDescriptor[] getDescriptors(); ... } If so I think the following is better interface Structure { String[] getFieldNames(); Field[] getFields(); } Thus structure of arrays is better than array of structures. Greg taught this to me :-) Or did you mean something else? > > It will bring the classical description of the composite type: > > 1. Structure has members > 2. Each member has name and type Remember that name and type not enough. If type is scalar then also want scalarType. If type is scalarArray then also want scalarType for elements. If structureArray also want Structure for elements If structure also want "Field[] fields" and "String[] fieldNames" for subfields of Structure. Marty > > -Nikolay > > -----Original Message----- > From: Marty Kraimer [mailto:mrk...@co...] > Sent: Monday, March 05, 2012 4:22 PM > To: epi...@li... > Subject: Move location of fieldName from Field to Structure > > It appears that several people, at least David, Benjamin, Matej, and Andrew, think it is a mistake to make the fieldName belong to Field. > > How about the following: > > Currently Field and Structure are defined as folllows: > > public interface Field { > String getFieldName(); > Type getType(); > void toString(StringBuilder buf); > void toString(StringBuilder buf,int indentLevel); > String toString(); > } > public interface Structure extends Field{ > Field getField(String fieldName); > int getFieldIndex(String fieldName); > Field[] getFields(); > } > > Change this to: > > public interface Field { > Type getType(); > void toString(StringBuilder buf); > void toString(StringBuilder buf,int indentLevel); > String toString(); > } > public interface Structure extends Field{ > Field getField(String fieldName); > int getFieldIndex(String fieldName); > Field[] getFields(); > String getFieldName(Field field); > String[] getFieldNames(); > } > > There will also be some changes to FieldCreate and maybe to PVDataCreate. > > I looked for calls to getFieldName in the src tree for pvDataJava, pvAccessJava, and pvIOCJava and found: > > pvDataJava/src 39 calls > pvAccessJava/src 4 calls > pvIOCJava/src 43 calls. > > I looked at a few instances and see only minor changes in the code. > Thus it looks like it will not be a major effort to implement the above change. > > > Marty > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > |
From: Marty K. <mrk...@co...> - 2012-03-07 12:16:40
|
Greg, While looking at possible memory leaks I found a problem when a RPC server terminates. I want to commit some changes to pvIOCCPP. Is this OK or does it affect beta releases? Marty |
From: Marty K. <mrk...@co...> - 2012-03-07 11:22:03
|
On 03/06/2012 04:16 PM, Andrew Johnson wrote: > Hi Marty, > > On 2012-03-06 Marty Kraimer wrote: >> Instead this becomes: >> >> public boolean attach(PVField pvField) { >> PVStructure pvStructure = null; >> >> if(!pvField.getParent().getFieldName(pvField).equals("control")) >> { >> >> if(!pvField.getParent().getFieldName(pvField).equals("value")) { >> ... >> >> Thus even more simple and more efficient. > It looks to me like PVField could have a convenience method getOwnName() or > even just getName() I would make getFieldName() a method of PVField Thus PVField has additional method: String getFieldName(); // returns the name of the PVField itself or an empty string if it is a top level field If we have this then PVStructure::getFieldName(PVField pvField) does not appear to be necessary. Thus only have PVField::getFieldName(); Structure still has methods: String[] getFieldNames() Field[] getFields(); > if that's not already used, which just does: > > return this.getParent().getFieldName(this); > > With that your example gets even shorter: > > public boolean attach(PVField pvField) { > PVStructure pvStructure = null; > > if (!pvField.getName().equals("control")) > { ... } > if (!pvField.getName().equals("value")) > { ... } > > What do top-level PVField objects do in getParent()? return null. Another argument for PVField::getFieldName() instead of PVStructure::getFieldName(PVField pvField) With this Andrews example works except for getFieldName instead of getName. I do not like just getName because it is too generic. If everything uses getName instead of some context specific name like getXXXName then it becomes really hard to use grep to look for problems. Marty > > - Andrew |
From: <jam...@di...> - 2012-03-07 08:18:52
|
Hi Guobao No there isn't, to fix the build temporarily put the site-specific information back into configure/RELEASE James ________________________________________ From: Shen, Guobao [sh...@bn...] Sent: 07 March 2012 02:07 To: epi...@li... Subject: FW: Build failed in Jenkins: pvIOCCPP - Build #224 Is there any RELEASE.local on JENKINS server for this module to avoid this build error? Guobao ________________________________________ From: Jenkins Build Server [no...@bn...] Sent: Tuesday, March 06, 2012 9:03 PM To: epi...@li... Subject: Build failed in Jenkins: pvIOCCPP - Build #224 See <https://irmis-dev.bnl.gov/jenkins/job/pvIOCCPP%20-%20Build/224/changes> Changes: [Guobao Shen] remove site specific configuration ------------------------------------------ Started by an SCM change Building remotely on irmis-dev [pvIOCCPP] $ hg incoming --quiet --bundle hg.bundle --template "<changeset node='{node}' author='{author|xmlescape}' rev='{rev}' date='{date}'><msg>{desc|xmlescape}</msg><added>{file_adds|stringify|xmlescape}</added><deleted>{file_dels|stringify|xmlescape}</deleted><files>{files|stringify|xmlescape}</files><parents>{parents}</parents></changeset>\n" --rev default [pvIOCCPP] $ hg unbundle hg.bundle adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files (run 'hg update' to get a working copy) [pvIOCCPP] $ hg update --clean --rev default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved [pvIOCCPP] $ hg log --rev . --template {node} [pvIOCCPP] $ /bin/sh -xe /tmp/hudson7653968229631089287.sh + cp configure/RELEASE configure/RELEASE.bak + sed s/^EPICS_BASE=.*/EPICS_BASE=\/usr\/lib\/epics/ configure/RELEASE.bak + sed s/^PVDATA=.*/PVDATA=\$\(TOP\)\/.\.\/pvDataCPP/ configure/RELEASE.tmp + sed s/^PVACCESS=.*/PVACCESS=\$\(TOP\)\/.\.\/pvAccessCPP/ configure/RELEASE.tmp2 + make clean all configure/CONFIG:17: /configure/CONFIG: No such file or directory configure/RULES_TOP:2: /configure/RULES_TOP: No such file or directory make: *** No rule to make target `/configure/RULES_TOP'. Stop. Build step 'Execute shell' marked build as failure Build failed. Publishing Doxygen skipped. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |
From: Matej S. <mat...@co...> - 2012-03-07 06:07:01
|
Hi, > $ hg head > changeset: 92:c65abc39fa07 > tag: tip > user: Guobao Shen > date: Tue Mar 06 21:01:54 2012 -0500 > summary: remove site specific configuration > > changeset: 46:e6abf140a3b9 > user: Matej Sekoranja > date: Thu May 19 09:14:52 2011 +0200 > summary: shared pointers usage This is what's left when me and Marty where debugging shared pointers. Just do: hg merge tip I'll remove my 9 months old changeset during the day.... Matej |
From: Shen, G. <sh...@bn...> - 2012-03-07 02:20:37
|
Is it time to tip another snapshot? Is there any significant function improvement or bug-fix to be checked in? I am asking this because our physicist is strongly pushing the release of my MASAR server. I think it is time to take a snapshot of our V4 CPP modules and release a Debian binary package since we do not have any binary release yet. Guobao |
From: Shen, G. <sh...@bn...> - 2012-03-07 02:11:30
|
Is the head (changeset 46 by Matej, which is 9 months old) still active? I think the answer is no. Should we merge them? $ hg head changeset: 92:c65abc39fa07 tag: tip user: Guobao Shen date: Tue Mar 06 21:01:54 2012 -0500 summary: remove site specific configuration changeset: 46:e6abf140a3b9 user: Matej Sekoranja date: Thu May 19 09:14:52 2011 +0200 summary: shared pointers usage Guobao |
From: Shen, G. <sh...@bn...> - 2012-03-07 02:07:57
|
Is there any RELEASE.local on JENKINS server for this module to avoid this build error? Guobao ________________________________________ From: Jenkins Build Server [no...@bn...] Sent: Tuesday, March 06, 2012 9:03 PM To: epi...@li... Subject: Build failed in Jenkins: pvIOCCPP - Build #224 See <https://irmis-dev.bnl.gov/jenkins/job/pvIOCCPP%20-%20Build/224/changes> Changes: [Guobao Shen] remove site specific configuration ------------------------------------------ Started by an SCM change Building remotely on irmis-dev [pvIOCCPP] $ hg incoming --quiet --bundle hg.bundle --template "<changeset node='{node}' author='{author|xmlescape}' rev='{rev}' date='{date}'><msg>{desc|xmlescape}</msg><added>{file_adds|stringify|xmlescape}</added><deleted>{file_dels|stringify|xmlescape}</deleted><files>{files|stringify|xmlescape}</files><parents>{parents}</parents></changeset>\n" --rev default [pvIOCCPP] $ hg unbundle hg.bundle adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files (run 'hg update' to get a working copy) [pvIOCCPP] $ hg update --clean --rev default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved [pvIOCCPP] $ hg log --rev . --template {node} [pvIOCCPP] $ /bin/sh -xe /tmp/hudson7653968229631089287.sh + cp configure/RELEASE configure/RELEASE.bak + sed s/^EPICS_BASE=.*/EPICS_BASE=\/usr\/lib\/epics/ configure/RELEASE.bak + sed s/^PVDATA=.*/PVDATA=\$\(TOP\)\/.\.\/pvDataCPP/ configure/RELEASE.tmp + sed s/^PVACCESS=.*/PVACCESS=\$\(TOP\)\/.\.\/pvAccessCPP/ configure/RELEASE.tmp2 + make clean all configure/CONFIG:17: /configure/CONFIG: No such file or directory configure/RULES_TOP:2: /configure/RULES_TOP: No such file or directory make: *** No rule to make target `/configure/RULES_TOP'. Stop. Build step 'Execute shell' marked build as failure Build failed. Publishing Doxygen skipped. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ |
From: Jenkins B. S. <no...@bn...> - 2012-03-07 02:03:21
|
See <https://irmis-dev.bnl.gov/jenkins/job/pvIOCCPP%20-%20Build/224/changes> Changes: [Guobao Shen] remove site specific configuration ------------------------------------------ Started by an SCM change Building remotely on irmis-dev [pvIOCCPP] $ hg incoming --quiet --bundle hg.bundle --template "<changeset node='{node}' author='{author|xmlescape}' rev='{rev}' date='{date}'><msg>{desc|xmlescape}</msg><added>{file_adds|stringify|xmlescape}</added><deleted>{file_dels|stringify|xmlescape}</deleted><files>{files|stringify|xmlescape}</files><parents>{parents}</parents></changeset>\n" --rev default [pvIOCCPP] $ hg unbundle hg.bundle adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files (run 'hg update' to get a working copy) [pvIOCCPP] $ hg update --clean --rev default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved [pvIOCCPP] $ hg log --rev . --template {node} [pvIOCCPP] $ /bin/sh -xe /tmp/hudson7653968229631089287.sh + cp configure/RELEASE configure/RELEASE.bak + sed s/^EPICS_BASE=.*/EPICS_BASE=\/usr\/lib\/epics/ configure/RELEASE.bak + sed s/^PVDATA=.*/PVDATA=\$\(TOP\)\/.\.\/pvDataCPP/ configure/RELEASE.tmp + sed s/^PVACCESS=.*/PVACCESS=\$\(TOP\)\/.\.\/pvAccessCPP/ configure/RELEASE.tmp2 + make clean all configure/CONFIG:17: /configure/CONFIG: No such file or directory configure/RULES_TOP:2: /configure/RULES_TOP: No such file or directory make: *** No rule to make target `/configure/RULES_TOP'. Stop. Build step 'Execute shell' marked build as failure Build failed. Publishing Doxygen skipped. |
From: Greg W. <gw...@st...> - 2012-03-06 22:24:12
|
Hi fellas, I just want you to know that I'm reading all emails in exquisite detail and have the answers to all our problems. Not! There's just too much powder snow here in Zermatt! I'll be back at work on Monday. And maybe functional by Wednesday. Greg Sent from my iSpeelingchanger |
From: Benjamin F. <ben...@he...> - 2012-03-06 21:23:50
|
On Dienstag, 6. März 2012, Andrew Johnson wrote: > What do top-level PVField objects do in getParent()? Return null, I'd guess. ________________________________ Helmholtz-Zentrum Berlin für Materialien und Energie GmbH Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V. Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph Geschäftsführerin: Prof. Dr. Anke Rita Kaysser-Pyzalla Sitz Berlin, AG Charlottenburg, 89 HRB 5583 Postadresse: Hahn-Meitner-Platz 1 D-14109 Berlin http://www.helmholtz-berlin.de |
From: Andrew J. <an...@ap...> - 2012-03-06 21:16:46
|
Hi Marty, On 2012-03-06 Marty Kraimer wrote: > Instead this becomes: > > public boolean attach(PVField pvField) { > PVStructure pvStructure = null; > > if(!pvField.getParent().getFieldName(pvField).equals("control")) > { > > if(!pvField.getParent().getFieldName(pvField).equals("value")) { > ... > > Thus even more simple and more efficient. It looks to me like PVField could have a convenience method getOwnName() or even just getName() if that's not already used, which just does: return this.getParent().getFieldName(this); With that your example gets even shorter: public boolean attach(PVField pvField) { PVStructure pvStructure = null; if (!pvField.getName().equals("control")) { ... } if (!pvField.getName().equals("value")) { ... } What do top-level PVField objects do in getParent()? - Andrew -- Never interrupt your enemy when he is making a mistake. -- Napoleon Bonaparte |
From: Benjamin F. <ben...@he...> - 2012-03-06 21:01:18
|
On Dienstag, 6. März 2012, Marty Kraimer wrote: > > I suggest a method on PVStructure::getFieldName(PVField pvField), this > > method actually does: > > > > Structure fieldStructure = (Structure)pvField.getField(); > > String fieldName = > > fieldStructure.getFieldNames()[pvField.getFieldOffset()]; > > > > You simply use fieldOffset. > > [...] > Thus even more simple and more efficient. Yes, yes, yes. Can I make one further (small) suggestion? Currently interface PVField has interface PVField extends Serializable, Requester { ... int getNumberFields(); ... } I believe this method can (and thus should) be factored out into the introspection interface. I would also rename it to getNumberSubFields to emphasize that it means /all/ fields directly or indirectly contained in this field (including the field itself), i.e. recursively. Cheers Ben ________________________________ Helmholtz-Zentrum Berlin für Materialien und Energie GmbH Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V. Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph Geschäftsführerin: Prof. Dr. Anke Rita Kaysser-Pyzalla Sitz Berlin, AG Charlottenburg, 89 HRB 5583 Postadresse: Hahn-Meitner-Platz 1 D-14109 Berlin http://www.helmholtz-berlin.de |