Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #14939 > unrolled thread

unchecked conversion warning.

Back to article view | Back to comp.lang.java.programmer

Contents

  unchecked conversion warning. Jens - 2012-05-30 15:32 +0200
    Re: unchecked conversion warning. Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-05-30 13:48 +0000
      Re: unchecked conversion warning. Jens - 2012-05-30 15:52 +0200
    Re: unchecked conversion warning. Robert Klemme <shortcutter@googlemail.com> - 2012-05-30 07:54 -0700
      Re: unchecked conversion warning. Jens - 2012-05-31 22:23 +0200
        Re: unchecked conversion warning. Lew <lewbloch@gmail.com> - 2012-05-31 13:40 -0700
        Re: unchecked conversion warning. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-31 16:50 -0400
          Re: unchecked conversion warning. Lew <lewbloch@gmail.com> - 2012-05-31 17:18 -0700
          Re: unchecked conversion warning. Robert Klemme <shortcutter@googlemail.com> - 2012-06-01 08:14 +0200
            Re: unchecked conversion warning. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-01 08:48 -0400
              Re: unchecked conversion warning. Robert Klemme <shortcutter@googlemail.com> - 2012-06-01 07:32 -0700
              Re: unchecked conversion warning. Roedy Green <see_website@mindprod.com.invalid> - 2012-06-10 12:16 -0700
                Re: unchecked conversion warning. Martin Gregorie <martin@address-in-sig.invalid> - 2012-06-10 22:08 +0000
                  Re: unchecked conversion warning. Lew <noone@lewscanon.com> - 2012-06-10 17:09 -0700
                    Re: unchecked conversion warning. Martin Gregorie <martin@address-in-sig.invalid> - 2012-06-11 01:31 +0000
          Re: unchecked conversion warning. Jim Janney <jjanney@shell.xmission.com> - 2012-06-01 08:41 -0600
            Re: unchecked conversion warning. Patricia Shanahan <pats@acm.org> - 2012-06-01 08:44 -0700
              Re: unchecked conversion warning. markspace <-@.> - 2012-06-01 09:08 -0700
              Re: unchecked conversion warning. Gene Wirchenko <genew@ocis.net> - 2012-06-01 09:31 -0700
              Re: unchecked conversion warning. Jim Janney <jjanney@shell.xmission.com> - 2012-06-01 11:02 -0600
              Re: unchecked conversion warning. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-01 13:54 -0400
                Re: unchecked conversion warning. Patricia Shanahan <pats@acm.org> - 2012-06-01 16:44 -0700
                  Re: unchecked conversion warning. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-01 20:24 -0400
                    Re: unchecked conversion warning. Patricia Shanahan <pats@acm.org> - 2012-06-01 19:36 -0700
            Re: natural/native language capabilities (was: unchecked conversion warning.) Jim Janney <jjanney@shell.xmission.com> - 2012-06-01 11:01 -0600
          Re: unchecked conversion warning. Roedy Green <see_website@mindprod.com.invalid> - 2012-06-10 12:13 -0700
          Re: unchecked conversion warning. Arne Vajhøj <arne@vajhoej.dk> - 2012-06-20 19:28 -0400
    Re: unchecked conversion warning. Broad Liyn <broadliyn@gmail.com> - 2012-06-10 21:52 -0700
      Re: unchecked conversion warning. Lew <noone@lewscanon.com> - 2012-06-10 23:50 -0700
      Re: unchecked conversion warning. Patricia Shanahan <pats@acm.org> - 2012-06-11 00:06 -0700
        Re: unchecked conversion warning. Robert Klemme <shortcutter@googlemail.com> - 2012-06-16 15:17 +0200
          Re: unchecked conversion warning. Lew <lewbloch@gmail.com> - 2012-06-18 12:28 -0700
            Re: unchecked conversion warning. Robert Klemme <shortcutter@googlemail.com> - 2012-06-19 23:14 +0200
              Re: unchecked conversion warning. Lew <lewbloch@gmail.com> - 2012-06-19 17:15 -0700
        Re: unchecked conversion warning. Arne Vajhøj <arne@vajhoej.dk> - 2012-06-20 19:22 -0400
      Re: unchecked conversion warning. Arne Vajhøj <arne@vajhoej.dk> - 2012-06-20 19:20 -0400

Page 2 of 2 — ← Prev page 1 [2]

#14988

On 6/1/2012 11:44 AM, Patricia Shanahan wrote:
> On 6/1/2012 7:41 AM, Jim Janney wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid> writes:
>>
>>> (JavaDoc is both a blessing and a curse: It's a blessing in that
>>> developers *are* encouraged to write documentation, and it's a curse
>>> in that *developers* are encouraged to write documentation. ;)
>>
>> If I ever found myself screening applicants for a programming job (not
>> something that's ever likely to happen) I would be very tempted to ask
>> them to write a short essay. If you can write clearly then I know you
>> can think clearly too.
>>
>
> Help! I hate writing English essays, and was never very good at it.
>
> Perhaps I picked the wrong career, but it's a little late now that I'm
> retired on the proceeds of my ill-chosen career path. I needed to know
> that I would not be good at programming back in 1970.

     Pull the other one; it's got bells on.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#14996

On 6/1/2012 10:54 AM, Eric Sosman wrote:
> On 6/1/2012 11:44 AM, Patricia Shanahan wrote:
>> On 6/1/2012 7:41 AM, Jim Janney wrote:
>>> Eric Sosman<esosman@ieee-dot-org.invalid> writes:
>>>
>>>> (JavaDoc is both a blessing and a curse: It's a blessing in that
>>>> developers *are* encouraged to write documentation, and it's a curse
>>>> in that *developers* are encouraged to write documentation. ;)
>>>
>>> If I ever found myself screening applicants for a programming job (not
>>> something that's ever likely to happen) I would be very tempted to ask
>>> them to write a short essay. If you can write clearly then I know you
>>> can think clearly too.
>>>
>>
>> Help! I hate writing English essays, and was never very good at it.
>>
>> Perhaps I picked the wrong career, but it's a little late now that I'm
>> retired on the proceeds of my ill-chosen career path. I needed to know
>> that I would not be good at programming back in 1970.
>
> Pull the other one; it's got bells on.
>

Yes, I'm joking about reconsidering my choice of career, but if getting
a programming job in 1970 had depended on English writing skill, I would
have been rejected - I write much better now than I did then.

Patricia

[toc] | [prev] | [next] | [standalone]

#14997

On 6/1/2012 7:44 PM, Patricia Shanahan wrote:
> On 6/1/2012 10:54 AM, Eric Sosman wrote:
>> On 6/1/2012 11:44 AM, Patricia Shanahan wrote:
>>> On 6/1/2012 7:41 AM, Jim Janney wrote:
>>>> Eric Sosman<esosman@ieee-dot-org.invalid> writes:
>>>>
>>>>> (JavaDoc is both a blessing and a curse: It's a blessing in that
>>>>> developers *are* encouraged to write documentation, and it's a curse
>>>>> in that *developers* are encouraged to write documentation. ;)
>>>>
>>>> If I ever found myself screening applicants for a programming job (not
>>>> something that's ever likely to happen) I would be very tempted to ask
>>>> them to write a short essay. If you can write clearly then I know you
>>>> can think clearly too.
>>>>
>>>
>>> Help! I hate writing English essays, and was never very good at it.
>>>
>>> Perhaps I picked the wrong career, but it's a little late now that I'm
>>> retired on the proceeds of my ill-chosen career path. I needed to know
>>> that I would not be good at programming back in 1970.
>>
>> Pull the other one; it's got bells on.
>>
>
> Yes, I'm joking about reconsidering my choice of career, but if getting
> a programming job in 1970 had depended on English writing skill, I would
> have been rejected - I write much better now than I did then.

     Aside from pure linguistic tasks -- writing grammatically and
correct, spelling words propperly, punctuating well that, sort?
of thing -- The developer needs some skill at separating himself
from his own context when documenting his artifact.  The person
who wrote the code participated in the design discussions, knows
what approaches were considered and rejected (and why), remembers
only too clearly the bugs that were easy to fix and those that
kept him awake nights, and is aware that class X began as a bunch
of parallel `switch' statements in class Y before refactoring.
When he sets out to document class X, he may have a hard time
writing in a way that will be intelligible to someone who does
not share his prior knowledge.

     A documentor needs some of the same skills as a teacher, most
especially the knack of seeing things from the point of view of a
reader not yet versed in them.  "Empathy," if you will.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#14998

On 6/1/2012 5:24 PM, Eric Sosman wrote:
...
> Aside from pure linguistic tasks -- writing grammatically and
> correct, spelling words propperly, punctuating well that, sort?
> of thing -- The developer needs some skill at separating himself
> from his own context when documenting his artifact. The person
> who wrote the code participated in the design discussions, knows
> what approaches were considered and rejected (and why), remembers
> only too clearly the bugs that were easy to fix and those that
> kept him awake nights, and is aware that class X began as a bunch
> of parallel `switch' statements in class Y before refactoring.
> When he sets out to document class X, he may have a hard time
> writing in a way that will be intelligible to someone who does
> not share his prior knowledge.

I find it helpful to write unit tests and Javadocs at the same time.
Both require that sort of separation. Both require attention to extreme
and special cases.

Patricia

[toc] | [prev] | [next] | [standalone]

#14986 — Re: natural/native language capabilities (was: unchecked conversion warning.)

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Jim Janney <jjanney@shell.xmission.com> writes:
>>If I ever found myself screening applicants for a programming job (not
>>something that's ever likely to happen) I would be very tempted to ask
>>them to write a short essay.  If you can write clearly then I know you
>>can think clearly too.
>
>       »I've found that some of the best [Software ]developers
>       of all are English majors. They'll often graduate with
>       no programming experience at all, and certainly without
>       a clue about the difference between DRAM and EPROM.
>
>       But they can write. That's the art of conveying
>       information concisely and clearly. Software development
>       and writing are both the art of knowing what you're going
>       to do, and then lucidly expressing your ideas.«
>
> http://praisecurseandrecurse.blogspot.com/2007/03/english-majors-as-programmers.html
>
>       »Besides a mathematical inclination, an exceptionally
>       good mastery of one's native tongue is the most vital
>       asset of a competent programmer.«
>
>     Edsgar Dijkstra
>
>       »While sloppy writing does not invariably mean sloppy
>       thinking, we've generally found the correlation to be
>       strong -- and we have no use for sloppy thinkers.
>       If you can't yet write competently, learn to.«
>
>     Eric Raymond
>
> http://www.catb.org/~esr/faqs/hacker-howto.html#skills4
>
>       »The narrative measures of conjunction use, event
>       content, perspective shift, and mental state reference
>       were significantly predictive of later Math scores.«
>
> http://www.arts.uwaterloo.ca/%7Edoneill/papers/Storytelling%20and%20math.pdf

Not an original thought, obviously :-)

There are probably counter-arguments to be made, but I don't recollect
ever seeing one.  Not a well-written one, anyway...

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#15189

On Thu, 31 May 2012 16:50:24 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
someone who said :

>     There's nothing fundamentally wrong with Vector.  People will
>moan and wring their hands over the cost of its synchronized methods,
>but I haven't heard of any actual measurements.

Originally Vector was much slower than ArrayList then somebody souped
up the low level code for locking and most of the difference
disappeared. I am just repeating what I heard.

JComboBox insists on a Vector of choices. You also need it for code
you want to run under any version of Java. JTable constructor likes
Vectors though you can get around that.


-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Controlling complexity is the essence of computer programming.
~ Brian W. Kernighan 1942-01-01
.

[toc] | [prev] | [next] | [standalone]

#15467

On 5/31/2012 4:50 PM, Eric Sosman wrote:
> On 5/31/2012 4:23 PM, Jens wrote:
>> By the yway, Vector has been 'retrofitted'. From the docs:
>> "As of the Java 2 platform v1.2, this class was retrofitted to
>> implement the List
>> interface, making it a member of the  Java Collections Framework".
>
>      There's nothing fundamentally wrong with Vector.  People will
> moan and wring their hands over the cost of its synchronized methods,
> but I haven't heard of any actual measurements.

Java Performance Tuning / Jack Shirazi has some tests
in Chapter 10 (Threading).

The difference were significant for 1.2.2, 1.3.1, 1.3.1 server
and 1.4.0 but not for 1.4.0 server.

The versions indicates something about the age of book.

I would expect the difference to be small for newer JVM's.
Synchronization has been optimized.

Arne

[toc] | [prev] | [next] | [standalone]

#15201

在 2012年5月30日星期三UTC+8下午9时32分43秒，（未知）写道：
> This code compiles with an 'unchecked conversion' warning.
> I have tried various corrections, for example casting like (Vector<Object>), but to no
> avail.
> What am I doing wrong?l
> The code is the smallest demo I could make from the original application.
> 
> import java.util.Vector;
> public class genericsdemo
> {
>   private static Vector<Vector> vdata = new Vector<Vector>(); //a Vector of Vectors
>   private static Vector<Object> vrow  = new Vector<Object>(); //a row
> 
>   public static void main(String args[]) {
>     vrow.add(null); //two columns in the row
>     vrow.add(null);
> 
>     vdata.add(vrow); //add the row to the Vector of Vectors
> 
>     Vector vtmp = getrow(); //test
>   }
> 
>   private static Vector<Object> getrow() {
>     return vdata.elementAt(0);  //warning: [unchecked] unchecked conversion
>   }
> }
> 
> JensJ
1.vector is no longer being supported.
2.

[toc] | [prev] | [next] | [standalone]

#15202

Broad Liyn wrote:
> （未知）写道：
>> This code compiles with an 'unchecked conversion' warning.
>> I have tried various corrections, for example casting like (Vector<Object>), but to no
>> avail.
>> What am I doing wrong?l
>> The code is the smallest demo I could make from the original application.
>>
>> import java.util.Vector;
>> public class genericsdemo
>> {
>>    private static Vector<Vector>  vdata = new Vector<Vector>(); //a Vector of Vectors

Vector<Vector<?>>

>>    private static Vector<Object>  vrow  = new Vector<Object>(); //a row
>>
>>    public static void main(String args[]) {
>>      vrow.add(null); //two columns in the row
>>      vrow.add(null);
>>
>>      vdata.add(vrow); //add the row to the Vector of Vectors
>>
>>      Vector vtmp = getrow(); //test

Raw types are bad.

>>    }
>>
>>    private static Vector<Object>  getrow() {
>>      return vdata.elementAt(0);  //warning: [unchecked] unchecked conversion
>>    }
>> }
>>

> 1.vector is no longer being supported.
> 2.

Do you mean 'Vector', as in 'java.util.Vector'? Because spelling counts in Java.

If so, then you're mistaken, and if not, you need to explain what you mean.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#15203

On 6/10/2012 9:52 PM, Broad Liyn wrote:
> 在 2012年5月30日星期三UTC+8下午9时32分43秒，（未知）写道：
>> This code compiles with an 'unchecked conversion' warning.
>> I have tried various corrections, for example casting like (Vector<Object>), but to no
>> avail.
>> What am I doing wrong?l
>> The code is the smallest demo I could make from the original application.
>>
>> import java.util.Vector;
>> public class genericsdemo
>> {
>>    private static Vector<Vector> vdata = new Vector<Vector>(); //a Vector of Vectors
>>    private static Vector<Object> vrow  = new Vector<Object>(); //a row
>>
>>    public static void main(String args[]) {
>>      vrow.add(null); //two columns in the row
>>      vrow.add(null);
>>
>>      vdata.add(vrow); //add the row to the Vector of Vectors
>>
>>      Vector vtmp = getrow(); //test
>>    }
>>
>>    private static Vector<Object> getrow() {
>>      return vdata.elementAt(0);  //warning: [unchecked] unchecked conversion
>>    }
>> }
>>
>> JensJ
> 1.vector is no longer being supported.
> 2.
>


As of JDK 7, Vector is not even deprecated.

The documentation,
http://docs.oracle.com/javase/7/docs/api/java/util/Vector.html, says "If
a thread-safe implementation is not needed, it is recommended to use
ArrayList in place of Vector." which implies that Vector might be a
reasonable choice if thread safety is needed.

Personally, I prefer to use ArrayList as base, and wrap using
Collections.synchronizedCollection, but that is not mandatory.

Patricia

[toc] | [prev] | [next] | [standalone]

#15331

On 11.06.2012 09:06, Patricia Shanahan wrote:

> The documentation,
> http://docs.oracle.com/javase/7/docs/api/java/util/Vector.html, says "If
> a thread-safe implementation is not needed, it is recommended to use
> ArrayList in place of Vector." which implies that Vector might be a
> reasonable choice if thread safety is needed.
>
> Personally, I prefer to use ArrayList as base, and wrap using
> Collections.synchronizedCollection, but that is not mandatory.

I totally agree.  Btw, there is one interesting detail: JavaDoc of 
Collections.synchronizedList() and the other synchronized*() methods 
explicitly state that the mutex used for synchronizing is that of the 
returned object:

http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#synchronizedList%28java.util.List%29

No such statement is done about Vector.  So while the source code of 
Vector tells us that the Vector instance is used to synchronize the 
JavaDoc does not give any guarantee about that and - at least 
theoretically - Sun/Oracle could change that and synchronize on another 
instance.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#15385

Robert Klemme wrote:
> I totally agree.  Btw, there is one interesting detail: JavaDoc of 
> Collections.synchronizedList() and the other synchronized*() methods 
> explicitly state that the mutex used for synchronizing is that of the 
> returned object:
> 
> http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#synchronizedList%28java.util.List%29

I see no such promise there.

And in fact it's not true. The source for the 'synchronizedCollection()' family 
of methods reveals that there's a separate field 'mutex' of type 'Object' on 
which the methods synchronize.

> No such statement is done about Vector.  So while the source code of 
> Vector tells us that the Vector instance is used to synchronize the 
> JavaDoc does not give any guarantee about that and - at least 
> theoretically - Sun/Oracle could change that and synchronize on another 
> instance.

And that would rarely matter, unless a person were adding actions that tried to 
synchronize on the same monitor.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15427

On 18.06.2012 21:28, Lew wrote:
> Robert Klemme wrote:
>> I totally agree.  Btw, there is one interesting detail: JavaDoc of
>> Collections.synchronizedList() and the other synchronized*() methods
>> explicitly state that the mutex used for synchronizing is that of the
>> returned object:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#synchronizedList%28java.util.List%29
>
> I see no such promise there.

<quote>
It is imperative that the user manually synchronize on the returned list 
when iterating over it:

   List list = Collections.synchronizedList(new ArrayList());
       ...
   synchronized (list) {
       Iterator i = list.iterator(); // Must be in synchronized block
       while (i.hasNext())
           foo(i.next());
   }


Failure to follow this advice may result in non-deterministic behavior.
</quote>

Pardon, my wording was wrong: it's not explicitly stated but it follows 
immediately from the quote.  For me that was "explicit" enough. ;-)

> And in fact it's not true. The source for the 'synchronizedCollection()' family
> of methods reveals that there's a separate field 'mutex' of type 'Object' on
> which the methods synchronize.

Did you see how it's initialized?  It's initialized with this, i.e. the 
wrapper instance.  The field serves the sole purpose to be able to 
synchronize on a parent collection when a dependent collection is 
created (e.g. in 
java.util.Collections.SynchronizedRandomAccessList.subList(int, int)). 
So normally the monitor of the wrapper is used as illustrated by the 
JavaDoc quoted.

>> No such statement is done about Vector.  So while the source code of
>> Vector tells us that the Vector instance is used to synchronize the
>> JavaDoc does not give any guarantee about that and - at least
>> theoretically - Sun/Oracle could change that and synchronize on another
>> instance.
>
> And that would rarely matter, unless a person were adding actions that tried to
> synchronize on the same monitor.

No, it also matters in cases like the example quoted above, i.e. when 
you need to perform multiple operations on the Vector instance: when the 
monitor which the Vector instance uses internally is different from the 
one used for the external synchronization then you do not have thread 
safety.  Depending on the logic anything from inconsistent contents to 
CME can happen.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#15435

On Tuesday, June 19, 2012 2:14:06 PM UTC-7, Robert Klemme wrote:
> On 18.06.2012 21:28, Lew wrote:
> > Robert Klemme wrote:
> >> I totally agree.  Btw, there is one interesting detail: JavaDoc of
> >> Collections.synchronizedList() and the other synchronized*() methods
> >> explicitly state that the mutex used for synchronizing is that of the
> >> returned object:
> >>
> >> http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#synchronizedList%28java.util.List%29
> >
> > I see no such promise there.
> 
> <quote>
> It is imperative that the user manually synchronize on the returned list 
> when iterating over it:
> 
>    List list = Collections.synchronizedList(new ArrayList());
>        ...
>    synchronized (list) {
>        Iterator i = list.iterator(); // Must be in synchronized block
>        while (i.hasNext())
>            foo(i.next());
>    }
> 
> 
> Failure to follow this advice may result in non-deterministic behavior.
> </quote>
> 
> Pardon, my wording was wrong: it's not explicitly stated but it follows 
> immediately from the quote.  For me that was "explicit" enough. ;-)

Okay, I see what you're saying, but it doesn't follow immediately. 
You have to go through at least two logical steps.

> No, it also matters in cases like the example quoted above, i.e. when 
> you need to perform multiple operations on the Vector instance: when the 
> monitor which the Vector instance uses internally is different from the 
> one used for the external synchronization then you do not have thread 
>safety.  Depending on the logic anything from inconsistent contents to 
> CME can happen. 

Nope.

The successive operations can synchronize on a second monitor without 
harm even though the individual methods synchronize on the first one.
Provided all your code uses that monitor, of course, in addition to the 
default one.

But then the Javadoc's advice wouldn't be right, so therefore you are.

Thanks for the eye-opener.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15466

On 6/11/2012 3:06 AM, Patricia Shanahan wrote:
> On 6/10/2012 9:52 PM, Broad Liyn wrote:
>> 1.vector is no longer being supported.
>
> As of JDK 7, Vector is not even deprecated.
>
> The documentation,
> http://docs.oracle.com/javase/7/docs/api/java/util/Vector.html, says "If
> a thread-safe implementation is not needed, it is recommended to use
> ArrayList in place of Vector." which implies that Vector might be a
> reasonable choice if thread safety is needed.

For other readers: thread safety here is for single calls.

> Personally, I prefer to use ArrayList as base, and wrap using
> Collections.synchronizedCollection, but that is not mandatory.

That is what is considered best practice today.

Arne

[toc] | [prev] | [next] | [standalone]

#15465

On 6/11/2012 12:52 AM, Broad Liyn wrote:
> 1.vector is no longer being supported.

It is supported.

It is not deprecated.

It is generally considered best practice to use ArrayList
instead of Vector and has been so for many years.

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web